
Of^T WELT0RGANISAT10N FOR GEISTIGES EIGENTUM 

ITv^ A Internationales Bflro 

INTERNATIONALE ANMELDUNG VEROFFENTLICHT NACH DEM VERTRAG OBER DIE 
INTERNATIONALE ZUSAMMENARBEIT AUF DEM GEBIET PES PATENTWESENS (PCT) 



(51) Internationale Patentidassifikation 6 
G07F 7/08 



A2 



(11) Internationale VeroJTentlichungsnummer: WO 98/28718 

2. Juli 1998 (02.07.98) 



(43) Internationales 

Veroffentlichungsdatum: 



(21) Internationales Aktenzeichen: 

(22) Internationales Anmeldedatum: 



PCT/DE97/03012 

19. Dezember 1997 
(19.12.97) 



(30) Prloritatsdaten: 

196 54 187.5 

197 18 115.5 



23. Dezember 1996 (23.12.96) DE 
29. April 1997 (29.04.97) DE 



(71) Anmelder (Jur aiU Bestimmungsstaaien ausser US): CCS 

CHIPCARD & COMMUNICATION SYSTEMS GMBH 
[DE/DE]; Paizer-Wald-Strasse 34, D-81539 Munchen 
(DE). 

(72) Erfinder; und 

(75) Erfinder/Anmelder (nur Jur US)i ENGELHARDT, Holger 
[DE/DE]; Blankenburger Strasse 96, D-13156 Berlin 
(DE). HINZ, Michael [DE/DE]; Das Spenglershofchen 
11, D-34277 Fuldabrtfck (DE). KISSINGER, Stefan 
[DE/DE]; Wartburgstrasse 6, D-10823 Berlin (DE). 
GOLLNER, Michael [DE/DE]; Schwandorferstrasse 3, 
D-81549 MUnchen (DE). KUCHELMEISTER, Anton, J. 
[DE/DE]; Johann-Emmer-S trasse 5, D-80995 MOnchen 
(DE). SCHWIER, Andreas [DE/DE]; Philosophenweg 4, 
D-32429 Minden (DE). BURGER, Adelheid [DE/DE]; 
Gronauer Strasse 34 a, D-64625 Bensheim (DE). RAD- 



NOTI, Michael [DE/DE]; Bahnhofstrasse 42, D-85417 
Marzling (DE). 

(74)Anwa!t: BETTEN & RESCH; Reichenbachstrasse 19, 
D-80469 Munchen (DE). 



(81) Bestimmungsstaaten: AL, AM, AT, AU, AZ, BA, BB, BG, 
BR, BY, CA, CH, CN, CU, CZ, DK, EE, ES, FI, GB, 
GE, GH, GW, HU, ID, IL, IS, JP, KE, KG, KP, KR, KZ, 
LC, LK, LR, LS, LT, LU, LV, MD, MG, MK, MN, MW, 
MX, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, 
SL, TJ, TM, TR, TT, UA, UG, US, UZ, VN, YU, ZW, 
ARIPO Patent (GH, GM, KE, LS, MW, SD, SZ, UG, ZW), 
eurasisches Patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, 
TM), europaisches Patent (AT, BE, CH, DE, DK, ES, H, 
FR, GB, GR, IE, IT, LU, MC, NL, PT, SE), OAPI Patent 
(BF, BJ, CF, CG, a, CM, GA, GN, ML, MR, NE, SN, TD, 
TG). 



VerofTentllcht 

Ohne internationalen Recherchenbericht und erneut zu 
veroffentlichen nach Erhalt des Berichts. 




(54) Tide: CHIP CARD AND METHOD FOR ITS USE 

(54) Bezeichnung: CHIPKARTE UND VERFAHREN ZUR VERWENDUNG DER CHIPKARTE 
(57) Abstract 

The invention relates to a chip card for carrying out 
transactions in which value data representing units of mone- 
tary value or other, non-monetary entitlements is transferred 
between the card holder and at least one transaction partner 
(service provider) or is presented to the service provider for 
verification of such entitlements. The chip card is character- 
ized in that it comprises a memory in which the data required 
for carrying out the transactions is stored, and in that it has a 
device for loading the card with one or more card applications 
(VAS applications), which in each case permit transactions to 
be carried out between the cardholder and one or more service 
providers. 

(57) Zusammenfassung 
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Chipkarte, die zur Durchfuhrung von Transaktionen di- 
ent, bei denen geldwerte Einheiten oder andere nicht-monetare 
AnsprUche reprasentierende Wertdaten zwischen dem 
Karteninhaber und mindestens einem Transaktionspartner 
(Service-Provider) ubertragen oder dem Service-Provider zur 
Verifizicrung der Ansprilche vorgewiesen werden, wobei die 
Chipkarte einen Speicher umfafit, in dem zur DurchtTlhrung der 
Transaktionen erforderliche Daten abgespeichert werden, und 
die Chipkarte ferner folgendes aufweist eine Einrichtung zum 

Laden von einer oder mehreren Kartenanwendungen (VAS-Applikationen) auf die Karte, die jeweils die DurchfUhrung von Transaktionen 
zwischen dem Karteninhaber und einem oder mehreren Service-Provider ermeglichen. 
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Chipkarte und Verfahren zur Verwendung der Chipkarte 

Die Erfindung betrifft eine Chipkarte, ein Terminal zur Verwendung mit einer 
Chipkarte, ein Verfahren zur Verwendung der Chipkarte sowie ein 
5 Chipkartensystem. 

Es sind bereits Mikroprozessor-Chipkarten mit Zahlungsfunktion, z.B. elektronische 
Geldborsen, ec-Cash, Kreditfunktion usw. v im Einsatz und es sind je nach 
AusprSgung durch Organisationen, wie ZKA (Zentraler Kreditausschuft), VISA oder 
10 EMV (Europay Mastercard VISA), Vorgaben festgelegt, so daft sie als 
Zahlungsmittel („Geldersatz a ) verwendet werden kdnnen. Als beispielhafte 
Beschreibungen seien hier genannt: 

- ZKA, Zentraler KreditausschuR, "Schnittstellenspezifikation fur die ec-Karte mit 
15 Chip", 27.10.1995; 

- Europay International, "Integrated Circuit Card, Specification for Payment 
Systems, EMV'96", V3.0, 30-Jun-1996; 

- ISO/IEC 7816-4, "Information technology - Identification cards - Integrated 
circuit(s) cards with contacts, Part 4: Interindustry commands for interchange", 

20 01-09-1995; 

- prEN 1 546-1 , "Identification card systems - Inter-sector electronic purse, Part 1 : 
Definitions, concepts and structures", 15.03.1995; 

- prEN 1546-2, "Identification card systems - Inter-sector electronic purse, Part 2: 
Security architecture", 03.07.1995; 

25 - prEN 1 546-3, "Identification card systems - Inter-sector electronic purse, Part 3: 
Data elements and interchanges", 09.12.1994; 

Ein aktueller Oberblick uber Chipkarten ist zu finden in: 

30 - Stefan SchQtt, Bert Kohlgraf: "Chipkarten, Technische Merkmale, Normung, 
Einsatzgebiete", R. Oldenbourg Verlag, Munchen/Wien, 1996, ISBN 3-486- 
23738-1. 
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Herkommliche Chipkarten sind regelmaftig nur fur einen bestimmten 
Anwendungszweck, beispielsweise als elektronische Geldbdrse oder als 
elektronischer Ausweis, nutzbar. Die auf diesen Chipkarten aufgebrachten 
5 Anwendungen sind jedoch regelmaiiig statisch, d.h. sie werden bei der Herstellung 
der Chipkarte aufgebracht und bleiben Ober den Lebenszyklus der Karte hinweg 
unverSndert bestehen. 

Herkfimmliche Chipkarten sind also sowohl hinsichtlich ihrer Variabilitat als auch 
10 hinsichtlich ihrer Funktionalitat beschrSnkt. Insbesondere sind herkdmmliche 
Chipkarten nach dem Herstellungsprozefi hinsichtlich ihrer Funktionalitat festgelegt 
und nicht mehr veranderbar. 

Es ist daher eine Aufgabe der vorliegenden Erfindung, eine Chipkarte zu schaffen, 
15 deren Funktionalitat variabel ist. 

Eine weitere Aufgabe der Erfindung besteht darin, eine Chipkarte zu schaffen, bei 
der die Zahl und Art der mit der Chipkarte durchfOhrbaren Applikationen bzw. 
Anwendungen und Transaktionen auch nach dem Herstellungsprozeli noch 
20 variabel ist. Es soli moglich sein, auf diese Chipkarte zusatzliche Applikationen "zu 
laden", es sollen Applikationen von der Chipkarte geloscht werden kdnnen und die 
einzelnen Applikationen sollen daten- und sicherheitstechnisch unabhangig 
voneinander definiert sein und unabhangig voneinander ablaufen. 

25 Die Chipkarte soil beispielsweise die daten- und sicherheitstechnischen 
Voraussetzungen nach ISO 7816 erfullen; die einzelnen Applikationen der Karte 
sollen jedoch insbesondere von der Kartenplattform selbst unabhangig sein. 

Es ist eine weitere Aufgabe der Erfindung, eine Chipkarte zu schaffen, bei der der 
30 Benutzer die Anzahl und Art der in seiner Karte verfugbaren Applikationen selbst 
bestimmen bzw. zusammenstellen und andem kann. 
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Es ist ferner eine Aufgabe der vorliegenden Erfindung, eine Chipkarte zu schaffen, 
mit der sowohl Intraservices (d.h. geschlossene Applikationen in dem Sinne, daft 
keine Abrechnung und Leistungsubertragung mit externen Partnern zu erfolgen 
hat) als auch Interservices (d.h. Applikationen mit zusatzlichen Aulienbeziehungen 
5 zu externen Partnern) ermdglicht und durchgefuhrt werden konnen. 

Gemaii einem Aspekt der Erfindung ist eine Einrichtung vorgesehen, mit der eine 
oder mehrere Kartenanwendungen auf die Karte geladen werden kbnnen, mit 
denen jeweils die DurchfQhrung von Transaktionen zwischen dem Karteninhaber 
10 und einem oder mehreren Service-Providern ermfiglicht wird. 

Durch das Laden wird die Chipkarte so konfiguriert, dad sie eine neue 
Funktionalitat erhait, d.h. eine Applikation ausfUhren kann, die ihr bisher nicht 
moglich war. Durch die geladenen Daten werden Applikationen definiert und in 
15 Verbindung mit den Grundfunktionalitaten der Karte wie etwa dem Betriebssystem 
realisiert, die vorher nicht auf der Karte vorhanden waren. Damit wird die 
Funktionalitat der Karte durch das Laden einer Applikation urn eben diese 
Applikation erweitert. 

20 Gemaii einem Ausfuhrungsbeispiel der Erfindung ist auf der erfindungsgemalien 
Chipkarte eine Datenstruktur (DF_VAS) vorgesehen, die selbst wiederum in eine 
Teilstruktur und einen Definitionsdatensatz unterteilt ist, wobei die Datenstruktur 
mittels einer sie identifizierenden Kennung eindeutig identifiziert ist und somit von 
der Kartenplattform an sich unabhangig ist. In die Teilstruktur kdnnen nun 

25 sogenannte Applikationen geladen werden, d.h. Funktionalitaten oder 
Anwendungen. der Chipkarte. Damit wird es durch Laden einer bestimmten 
Applikation der Chipkarte mOglich, Transaktionen zwischen dem Karteninhaber und 
einem fur diese Applikation spezifischen Service-Provider durchzufDhren. Ein 
Definitionsdatensatz innerhalb der Datenstruktur enthait Informationen ilber die Art 

30 und/oder die Struktur der in der Teilstruktur geladenen Applikationen. Zumindest 
der Definitionsdatensatz, vorzugsweise jedoch die gesamte Datenstruktur sind 
mittels mindestens eines Systemschlussels gegen Modifikationen abgesichert und 
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nur unter Verwendung dieses SchlQssels modifizierbar. Anstelle eines 
Systemschlussels sind auch andere Sicherungsmechanismen Oder 
Sicheaingseinrichtungen vorstellbar, mittels derer die Absicherung gegen 
Modifikationen erfolgen kann, etwa durch eine personliche Kennziffer (PIN) Oder 
5 sonstige zur Absicherung dienende Einrichtungen. 

Mit der obigen Struktur ist es mOglich, in die Teilstruktur verschiedene 
Applikationen zu laden und diese auch wieder aus der Teilstruktur zu loschen, so 
daB die Karte hinsichtlich ihrer Funktionalitaten bzw. der mit ihr durchfOhrbaren 

10 Anwendungen variabel ist. Laden und LSschen von Applikationen geschieht durch 
Schreiben von applikationsspezifischen Daten und SchlQsseln in die vorhandene 
Teilstruktur. Durch Vorsehen des Systemschlussels und der Datenstrukturkennung 
wird die die Multifunktionalitat ermdglichende Datenstruktur unabhangig von der 
Kartenplattform an sich und auch hinsichtlich ihrer Sicherheitsarchitektur 

15 selbsttragend und unabhangig von der Kartenplattform. 

Abhangig von den in der Teilstruktur geladenen Applikationen konnen dann mittels 
der Karte Transaktionen zwischen dem Karteninhaber und Service-Providern, die 
von den geladenen Applikationen abhangig sind, durchgefuhrt werden. 

20 

Vorzugsweise weist die Chipkarte femer einen Transfer-Speicherbereich auf, in 
den die bei der DurchfQhrung von Transaktionen auszutauschenden Daten 
geschrieben bzw. aus dem sie gelesen werden. Indem fur das Entnehmen von 
Daten aus dem Transfer-Speicherbereich terminalspezifische Schlussel 
25 vorgesehen werden, sind die einzelnen Zugriffe sicherheitstechnisch voneinander 
unabhangig. 

Die einzelnen in der Karte vorhandenen Teilstrukturen bzw. Applikationen sind 
vorzugsweise voneinander unabhangig und jeweils einem bestimmten Service- 
30 Provider zugeordnet. Sie stellen sozusagen die fur diesen Service-Provider 
proprietaren oder spezifischen Daten zum DurchfGhren einer bestimmten 
Applikation dar. Sie enthalten deshalb je nach Applikationstyp und je nach Service- 
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Provider unterschiedliche Informationen, beispielsweise Daten, die einen 
bestimmten Wert reprasentieren (Bonuspunkte, Kontostand, etc.). 
Informationsdaten Qber die Applikation, Informationsdaten Qber den Service- 
Provider, etc. Vorzugsweise enthalten sie jedoch insbesondere auch fQr die 
5 Applikation spezifische Schlussel, mittels derer ein Zugriff auf die Daten der 
Teilstruktur auf sicherheitstechnisch von anderen Teilstrukturen unabhSngige Art 
und Weise ermOglicht wird. Das Laden oder Generieren der Teilstruktur bzw. 
Applikation selbst ist dagegen mit zumindest einem Qbergeordneten 
SystemschlQssel abgesichert. 

10 

Vorzugsweise findet vor dem Durchfuhren einer Transaktion eine gegenseitige 
Authentifizierung zwischen Chipkarte und einem Terminal statt, wobei dabei ein 
applikations- bzw. teilstrukturspeziflscher AuthentifizierungsschlQssel vorgesehen 
ist. 

15 

Zum Durchfuhren von Transaktionen werden dann Daten in eine fQr die jeweilige 
VAS-Applikation reservierte Teilstruktur geschrieben oder daraus gelesen oder 
Qber den Transfer-Speicherbereich abgewickelt. Im ersten Fall werden 
applikationsspezifische Schlussel verwendet. Im letzteren Fall wird ein 

20 applikationsspezifischer und vorzugsweise auch ein terminalspezifischer Schlussel, 
der beispielsweise mittels eines SchlQssel-Erzeugungsschlussels, der auf der Karte 
vorgesehen ist und aus applikationsspezifischen Daten generiert wird, verwendet. 
Die so in den Transferspeicher geschriebenen Daten kfinnen dann vom Service- 
Provider Qber das Terminal entnommen werden, was vorzugsweise durch 

25 Kennzeichnen der im Transferspeicher gespeicherten Daten als entwertet 
geschieht. Handelt es sich dabei urn einen Service-Provider, der nicht fur die 
schreibende Applikation spezifisch ist, so wird dadurch ein sogenannter 
Interservice ausgefuhrt, d.h. es werden zum Nutzen bzw. auf Kosten des 
Karteninhabers geldwerte Daten zwischen unterschiedlichen Service-Providern 

30 ausgetauscht. 
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Als zusatzliche Sicherung ist femer eine PIN Oder ein Paliwort zur Verifikation der 
Berechtigung eines Transaktionsvorgangs vorgesehen. 

Durch die variable Struktur der Karte kdnnen zu verschiedenen Zeitpunkten 
5 verschiedene Applikationen in unterschiedlicher Anzahl auf der Karte 
untergebracht sein. 

Die Echtheit von aus dem Transfer-Speicher entnommenen Daten wird 
vorzugsweise unter Verwendung eines SignierschlQssels bzw. unter Verwendung 

10 einer digitalen Unterschrift oder mindestens eines Schliissels gesichert. Besonders 
vorteilhaft ist es dabei, wenn die entnommenen Daten weiter im Transfer-Speicher 
verbleiben, jedoch lediglich durch die Karte als entnommen gekennzeichnet 
werden. Dadurch k6nnen auch nach der Transaktion noch Informationen Qber die 
durchgefOhrte Transaktion erhalten werden. Damit und mit der Absicherung der 

15 Entnahme ist auch Einmaligkeit nachweisbar. 

Besonders vorteilhaft ist es ferner, wenn die in den Transfer-Speicher 
geschriebenen Daten mit einem Verfallsdatum gekennzeichnet sind, nach dem sie 
ihren Wert verlieren. Dadurch werden Applikationen realisierbar, die beispielsweise 
20 die Bereitstellung eines fur einen bestimmten Zeitraum gtlltigen Tickets 
ermfiglichen. 

Mittels eines vorzugsweise vorgesehenen TransaktionszShlers kflnnen die 
Transaktionsdaten bzw. die Wertdaten hinsichtlich ihrer zugeharigen Transaktion 
25 eindeutig bestimmt und identifiziert werden. 

Die erfindungsgema&e Chipkarte besteht in einer vorteilhaften AusfQhrungsform 
also aus einem hierarchischen Speicherkonzept, das auf seinen unterschiedlichen 
Ebenen mittels verschiedener SchlQssel gegen Modifikationen abgesichert ist, das 
30 auf der Ebene der Applikationen hinsichtlich der in den Speicher geladenen 
Applikationen variabel ist, wobei jede einzelne Applikation durch eigene spezifische 
SchlQssel gegenOber anderen abgesichert und von diesen unabhSngig ist, und 
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wobei die Gesamtstruktur mittels mindestens eines Systemsschlussels und mittels 
einer die Struktur identifizierenden Kennung gesichert und von der Kartenplattform 
selbst unabhangig ist. Das Konzept des Transferspeichers ermOglicht den 
Austausch von Daten sowohl zwischen Karteninhaber und Service-Provider als 

5 auch zwischen unterschiedlichen Service-Providern selbst. Auch das Lesen und 
Schreiben in den bzw. aus dem Transferspeicher ist durch SchlQssel abgesichert, 
wobei diese ebenfalls karten- und appplikationsspezifisch, zusatzlich jedoch auch 
noch terminalspezifisch sind. Eine Authentifizierung, die vor jeder Transaktion 
durchgefQhrt wird, sowie optional eine PIN oder ein Paftwort erhflhen zusatzlich die 

10 Sicherheit der erfindungsgemaiJen Chipkarte. 

In den Patentanspriichen 21 bis 30 wird ein Terminal zur Verwendung mit der 
erfindungsgemaiien Chipkarte definiert. Dieses Terminal dient zum Laden oder 
Ldschen von Applikationen, zur Durchfuhrung von Transaktionen, zum Ansehen 

15 von Daten sowie zur Durchfuhrung von weiteren in Verbindung mit den jeweiligen 
Applikationen und Transaktionen stehenden Funktionen. Ein Verfahren zum 
Durchfuhren von Transaktionen zwischen Karteninhaber und Service-Provider ist in 
den Ansprtlchen 31 bis 33 definiert, das Laden von Daten auf eine 
erfindungsgemaiJe Chipkarte definieren AnsprQche 34 und 35, und Anspruch 36 

20 definiert ein Gesamtsystem aus Chipkarte und Terminal. 

Nachfolgend wird die vorliegende Erfindung anhand eines bevorzugten 
AusfOhrungsbeispiels naher beschrieben, wobei Bezug auf die beiliegenden 
Zeichnungen genommen wird. Dabei zeigen 

25 

Fig. 1 schematisch die erfindungsgemafte Chipkarte, 

Fig. 2 eine schematische Darstellung des Gesamtsystems der Komponenten 
der Erfindung, 

30 



Fig. 3 den DatenfluB im Gesamtsystem, 
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Fig. 4 die mfiglichen Applikationsklassen und Operationen durch ein 
Transaktionsmodell in schematischer Darstellung, 

Fig. 5 eine schematische Darstellung der Sicherheitsarchitektur der 
erfindungsgema&en Chipkarte, 

Fig. 6 die Dateistruktur einer allgemeinen Implementierungsklasse des VAS- 
Containers, 

Fig. 7 verschiedene Implementierungsklassen des VAS-Containers gemali 
einem AusfOhrungsbeispiel der vorliegenden Erfindung, 

Fig. 8 die Dateistruktur des VAS-Containers gemali einem 
AusfQhrungsbeispiel der vorliegenden Erfindung, 

Fig. 9 schematisch die Dateistruktur der Implementierungsklasse DFJPT, 

Fig. 10 schematisch die Dateistruktur der Implementierungsklasse DFAD. 

Bevor die Erfindung naher beschrieben wird, sollen einige, im nachfolgenden 
veiwendeten Begriffe definiert werden: 

VAS: Value Added Services 

WIS-Karfe: Die VAS-Karte ist eine Chipkarte, mit der an den Value Added Services 
teilgenommen werden kann. Die VAS-Karte enthait neben anderen Anwendungen 
wie z.B. Zahlungsapplikationen (also elektronische GeldbOrse) den VAS-Container. 

VAS-Container: Der VAS-Container beinhaltet Datenstrukturen, 
Zugriffsbedingungen, SchlQssel und (Erganzungs-) Kommandos zum Venvalten 
von VAS-Applikationen und der Bereitstellung der Funktionalitat der VAS- 
Applikationen. 
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VAS-Applikation: VAS-Applikationen enthalten VAS-Daten. Zugriff auf die VAS- 
Daten wird durch die VAS-Applikation gesteuert. Ein VAS-Provider betreibt im 
VAS-Container eine Oder mehrere VAS-Applikationen. Die Nutzung der VAS- 
5 Applikation definiert sich aus dem Aufbringen, Lesen und Verarbeiten von VAS- 
Daten. Eine VAS-Applikation kann entweder als Intra- Oder Interservice ausgepragt 
sein. 

VAS-Provider: Der VAS-Provider ist fQr seine VAS-Applikation verantwortlich, die er 
10 nach Rahmenbedingungen des System Operators und nach seinen eigenen 
Vorstellungen entwickelt und danach Qber den System Operator und die Terminals 
den Cardholders zur Verwendung bereitstellt. Die VAS-Applikationen sind in den 
VAS-Container der VAS-Karte zu laden, bevor daran teilgenommen werden kann. 

15 Intraservice: Intraservice ist eine Sorte von VAS-Applikation, die unter exklusiver 
Regie des jeweiligen VAS-Providers benutzt wird. Intraservice Applikationen sind 
geschlossene Applikationen in dem Sinne, daft keine Abrechnung Oder 
LeistungsQbertragung mit externen Partnern erfolgt. Eine VAS-Applikation kann 
entweder als Intra- oder Interservice ausgeprSgt sein. 



Interservices: Interservice Applikationen sind Intras.ervice Applikationen, die Qber 
zusatzliche Aulienbeziehungen zu externen Partnern unterhalten. Eine VAS- 
Applikation kann entweder als Intra- oder Interservice ausgeprSgt sein. 

25 SO, System Operator: Der System Operator, oder System Betreiber, bietet den 
VAS-Providern und den Cardholders das VAS-System zur Nutzung an. 

Issuer: Der Issuer, oder Kartenherausgeber, bringt die VAS-Karten mit VAS- 
Container in den Umlauf. 



CH, Cardholder: Der Cardholder, oder Karteninhaber, ist die Person, die die Karte 
(hien VAS-Karte) besitzt und einsetzt, urn an den Value Added Services 
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teilzunehrnen. Diese Person ist nicht zwangsiaufig der eigentliche Eigentumer der 
Karte. 

Serviceterminal: Das Serviceterminal wird vom System Operator fur VAS- 
5 Applikationen aufgestellt. Am Serviceterminal kann der Karteninhaber die VAS- 
Applikationen auf seiner VAS-Karte verwalten (Laden, Ansehen, Lflschen und 
Obertragen von VAS-Applikationen). 

HSndlerterminal: Das Handlerterminal besitzt Zahlungsfunktionen und bietet 
10 zusatzlich VAS-Funktionalitat. An ihm setzt der Karteninhaber seine VAS-Karte ein, 
urn einerseits zu bezahlen und gleichzeitig an den Vorteilen von VAS 
teilzunehrnen. 

AID: (Application Identifier) maximal 16 Byte langer Name von Applikationen zur 
15 eindeutigen Unterscheidung von Applikationen und der Applikationsselektion von 
aufien ohne Kenntnis der Dateistruktur einer Karte. Die AID besteht aus einer 5 
Byte langen Registered Application Provider ID (RID) und optional aus einer 
maximal 11 Byte langen Proprietary Application Identifier Registration (PIX). 

20 DF: Directory File nach ISO 7816 

EF: Elementary File nach ISO 7816 

Gultiger VAS-Container: VAS-Container, der sich gegenQber der externen Welt 
25 authentisieren kann. 

KID: (Key Identifier) Nummer eines SchlQssels innerhalb eines Elementary Files, 
das Schlussel enthait 

30 R&R: Rules and Regulations 

p: Maximale Zahl von Objekten der Implementierungsklasse DF_PT 
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a: Maximale Zahl von Objekten der Implementierungsklasse DF_AD 

nr DIR : Maximale Gesamtzahl von Objekten: nr DIR = p + a 
Die Anzahl von Records in EF_DIR ist nr DJR . 

"^transfer- Anzahl von Records des EF_TRANSFER 

Fig. 1 zeigt schematisch die Struktur der erfindungsgemaiien Chipkarte. Zusatzlich 
zu den statisch und nicht veranderbaren, beim Herstellungsprozeft aufgebrachten 
Daten wie dem Masterfile MF und der (optional vorhandenen) Geldbdrsenfunktion 
DF_B6rse ist auf der erfindungsgemaiien Karte noch ein Verzeichnis bzw. eine 
Datenstruktur Oder Dateistruktur DF_VAS vorgesehen. Diese dient zur Aufnahme 
von Zusatzfunktionalitaten, sogenannten Value Added Services VAS. Aufgrund 
dieser Zusatzfunktionalitaten, die Applikationen darstellen, die auch noch zu einem 
spateren Zeitpunkt, also nach der Herstellung der Karte, auf die Karte geladen 
werden kOnnen, ist die Karte hinsichtlich ihrer Funktionalitaten und der mit ihr 
durchfQhrbaren Transaktionen flexibel und variabel. Der auf der 
erfindungsgemaiien Chipkarte vorgesehene sogenannte VAS-Container (DF_VAS) 
ermoglicht die Variabilitat und Flexibilitat der Chipkarte bezuglich ihrer Funktionen 
und lost daneben die auf der Chipkarte untergebrachten Applikationen 
sicherheitstechnisch von der Kartenplattform, so daft diese von der Kartenplattform 
unabhangig sind und eventuell sogar auf eine andere Karte ubertragen werden 
kdnnen. 

Die erfindungsgemaften, neuen Zusatzfunktionalitaten (Value Added Services, 
VAS) werden realisiert durch Mikroprozessor-Chipkarten. Die Umsetzung dieser 
Zusatzfunktionalitaten wird durch den VAS-Container realisiert. Der VAS-Container 
auf der Mikroprozessor-Chipkarte bildet die Plattform zur Aufnahme der VAS- 
Applikationen. Die VAS-Applikationen sind die jeweiligen Realisierungen 
bestimmter Zusatzfunktionalitaten. 
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lm Fall der elektronischen Geldbftrse wird das Bezahlen mit der Karte 
(Zahlungsfunktion) und die Nutzung einer VAS-Applikation (Zusatzfunktionalitat) 
uber getrennte Mechanismen abgewickelt; aus Sicht des Kartennutzers bzw. 
Karteninhabers kann dies aber als ein Vorgang erscheinen. 



Die Mikroprozessor-Chipkarte wird erweitert urn den VAS-Container, der 
verschiedene und unabhangige Applikationen aufnehmen kann. Er stellt 
Funktionen zum Aufbringen, Laschen und Obertragen dieser Applikationen zur 
VerfOgung; diese konnen nur vom autorisierten Systembetreiber verwendet 

10 werden. Der VAS-Container ist daten- und sicherheitstechnisch unabhangig von 
anderen Systemkomponenten auf dem Mikroprozessor-Chip. Der VAS-Container 
ist vollstSndig durch sich selbst defmiert und allein funktionsfahig. FUr ihn ist eine 
unabhangige Sicherheitsarchitektur definiert, so daft VAS-Applikationen 
eigenstandige Sicherheitsfunktionen verwenden. Die Sicherheitsarchitektur 

15 verwendet kartenspezifische SchlGssel, die nicht herstellerspezifisch und die 
unabhangig von Identifikationsmerkmalen der Kartenplattform sind. 

Der VAS-Container verwendet auch Mechanismen zur Ableitung 
terminalspezifischer Schlussel. Mit diesen kann der VAS-Container selbst aktiv die 
20 Echtheit von Terminals bzw. die von ihnen erzeugten Daten prtifen. 

Im VAS-Container werden die VAS-Applikationen abgelegt, die Gber Mechanismen 
des VAS-Container Daten bereitstellen und dadurch die Steuerung der 
zugeordneten Schnittstellen bewerkstelligen. Der VAS-Container ermdglicht und 
25 steuert auch den sicheren Austausch von Daten ftlr Interservices zwischen 
Partnern. Der VAS-Container eriedigt aktiv die Kontrolle, d.h. die Echtheit und die 
Einmaligkeit, der Qbertragenen Datenwerte. 



5 



Ein Vorteil des VAS-Container gegenuber anderen Ansatzen von Multi- 
30 Applikations-Karten ist, daB dieses Konzept unabhangig von einer bestimmten 
Kartenplattform ist Es bietet eine Sicherheitsarchitektur, die unabhangig von 
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plattformspezifischen Sicherheltsmechanismen (wie Schliissel, 
Identifizierungsdaten, PIN, Signaturverfahren) ist. 

Ein weiterer Vorteil des Konzeptes VAS-Container ist, daft die Anzahl der 
verschiedenen Applikationen auf der Karte nicht fest vorgegeben ist durch 
Beschrankungen und Vorgaben zum Zeitpunkt der Kartenherstellung oder der 
Kartenausgabe; die aktuelle Kartenbelegung mit Anwendungen ist frei wahlbar 
durch den Kartennutzer und ist nur durch den auf der jeweiligen Karte zur 
Verfugung stehenden Speicherplatz beschrankt. Die Anzahl der aktuell auf einer 
Karte geladenen VAS-Applikationen hangt vom tatsachlichen Gebrauch der Karte 
ab. Der Kartennutzer stellt individuell die VAS-Applikationen auf seiner Karte 
zusammen; dies beinhaltet auch die Anderung der Zusammenstellung zu einem 
spateren Zeitpunkt. Der VAS-Container ermdglicht eine multifunktionale Karte, bei 
der die Kartenfunktionalitat wahrend des Lebenszyklus der Karte variabel in Anzahl 
und Art der Anwendungen zusammengestellt und verwendet werden kann. Es 
kdnnen so auch Anwendungen, fur die bislang einzelne, spezielle Karten 
notwendig waren, auf nur einer Karte abgelegt werden und zum Einsatz kommen. 
VAS-Applikationen kdnnen auch auf andere Karten Qbertragen werden. Damit 
kdnnen VAS-Applikationen den Lebenszyklus einer Karte uberieben; sie begleiten 
den Kartennutzer wahrend des Lebenszyklus der Anwendungen. 

Die Mikroprozessor-Chipkarte mit Zusatzdiensten ist ein geeignetes Medium zur 
Verbreitung und zur Vermarktung von Dienstleistungen, bei denen auf geschutzte 
Daten zugegriffen werden muft. Diese Mikroprozessor-Chipkarte kann als 
Zahlungsmittel, Recheneinheit und zur Wertaufbewahrung verwendet werden. Sie 
kann entsprechend dem Kundenwunsch vom Kunden selbst und nach 
Kartenausgabe flexibel mit Zusatzdiensten versehen und zu deren Steuerung 
herangezogen werden. Sie kontrolliert auch aktiv die Authentizitat von beteiligten 
Terminals und stellt die Einmaligkeit und Echtheit von ubergebenen Daten sicher. 



Fig. 2 zeigt eine Systemubersicht. Darin dargestellt sind die Systemkomponenten. 



WO 98/28718 



PCT/DE97/03012 



Ein Systembetreiber (System Operator) stellt das System zur Verfiigung. An 
Serviceterminals (ST) konnen VAS-Applikationen geladen, geldscht und 
Gbertragen werden; weitere Operationen sind: VAS-Applikation auswahlen, 
ansehen, interpretieren usw. 

Die Anbieter von VAS-Applikationen, die sogenannten VAS-Provider, entwerfen 
eigene VAS-Applikationen nach den Rahmenbedingungen des Systembetreibers 
und, soweit moglich, nach eigenen Vorstellungen. Durch AbschluB mit einer 
digitalen Unterschrift werden die entsprechenden Terminalprogramme auf Echtheit 
nachprQfbar. 

Fig. 3 zeigt den Datenfluft im System. 

Die VAS-Applikationen werden uber den Systembetreiber an den Terminals den 
Kartennutzern zur Verwendung bereitgestellt. VAS-Applikationen sind in den VAS- 
Container der erfindungsgemalien Chipkarte zu laden, bevor daran teilgenommen 
werden kann. 

An Handlerterminals (HT) werden auf der Karte vorhandene VAS-Applikationen 
genutzt, indem VAS-Daten aufgebracht bzw. geloscht werden. 

Zur Realisierung der Mikroprozessor-Chipkarte mit VAS-Funktionalitat wird neben 
anderen bestehenden Anwendungen (z.B. Zahlungsapplikationen wie die 
elektronische GeldbSrse) der VAS-Container auf der Karte aufgebracht. 

Der VAS-Container verwendet Funktionen, die ein Aufbringen, LOschen und 
Obertragen von VAS-Applikationen ermoglichen. Diese Verwaltungsfunktionen 
werden ausschlieRlich vom System Operator benutzt und sind in der Karte gegen 
Fremdbenutzung abgesichert. Der VAS-Container beinhaltet einen 
Transferspeicher, mit dem der Austausch von Daten zwischen VAS-Applikationen 
realisiert wird. 
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Zur Steuerung des Transferspeichers werden zwei Kommandos TRANSFER und 
TAKE eingesetzt. Das Kommando TRANSFER erzeugt einen Eintrag im 
Transferspeicher mit fQr die jeweilige Applikation spezifischen Daten. Neben den 
Nutzdaten zahlen hierzu auch die zur Steuerung der Verarbeitung notwendigen 
5 Angaben wie Datum, Verfallsdatum und Identifikationsdaten. Mit dem Kommando 
TAKE werden Objekte aus dem Transferspeicher entnommen und als entnommen 
markiert. Je nach Anwendungsfall werden die Objekte dann als weiterhin gQltig 
oder als ungOltig markiert. Obertragene Daten werden durch den VAS-Container 
auf Echtheit und Einmaligkeit uberpruft. 



VAS-Applikationen verwenden zur Bereitstellung und Steuerung der Anwendungen 
VAS-Daten. Zugriff auf die VAS-Daten wird durch die VAS-Applikation gesteuert, 
die sich dazu Mechanismen bedient, welche im VAS-Container alien Applikationen 
bereitgestellt sind. Ein VAS-Provider betreibt im VAS-Container eine oder mehrere 
15 VAS-Applikationen. Die Nutzung der VAS-Applikation definiert sich aus dem 
Aufbringen, Lesen und Verarbeiten von VAS-Daten. 

Der VAS-Container unterstutzt Interservices. Interservices erfordern Zugriff auf 
gemeinsame Daten, Gbertragung von Leistungsanspruchen und die Abrechnung 
20 von Leistungen zwischen verschiedenen Partnern. 

Im folgenden sollen die mit der erfindungsgemaUen Chipkarte moglichen Dienste 
bzw. Applikationen anhand von Beispielen aufgezeigt werden. 

25 Die Beschreibung bezieht sich jeweils auf die Erscheinungsweise und Funktion 
nach dem Stand der Technik. Die Funktion soil zukUnftig durch eine oder mehrere 

i 

VAS-Applikationen nachgebildet werden. 



10 



30 



Als erstes werden Intraservices vorgestellt. 
Beispiel A: Kundenclub 
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Ein Kaufhaus betreibt einen Kundenclub. Der Kunde wird in diesem Club Mitglied 
und erhalt mit diesem Status spezifische Clubleistungen, die Nichtmitglieder nicht 
erhalten konnen. Heute identifiziert sich ein Clubmitglied in der Clubumgebung 
durch einen Clubausweis. Der Clubausweis wird beim Eintritt erstellt, ist nicht 
Qbertragbar, und hat in der Regel eine GQItigkeitsdauer. Clber den Clubausweis 
werden keine spezifischen Transaktionen abgewickelt, d.h. es besteht keine 
Kopplung mit dem Kundenumsatz. Damit grenzt sich der Clubausweis von 
Bonusprogrammen ab, in denen ein Zusammenhang Status / Umsatz besteht. 

Analog: GroBhandler Ausweis, Senator Card, Buchclub 

Ziel: Die ClubzugehSrigkeit soli durch eine Applikation im VAS-Container 
nachgewiesen werden. 

Beispiel B: Bonussystem 

Ein Kunde erhalt fur jede Transaktion einen Bonusanspruch vergQtet. Der 
Bonusanspruch wird kumuliert und kann an einem durch den Kunden definierten 
Zeitpunkt fur eine geldwerte Leistung eingetauscht werden. Der Bonusanspruch gilt 
fur einen definierten Zeitraum und kann anonym Oder personenbezogen verwaltet 
werden. Der Bonusanspruch entsteht durch Umsatz oder Nutzungshaufigkeit. 

Analog: Punktestand von Miles & More 

Ziel: Das Punktekonto soil durch eine Applikation im VAS-Container verwaltet 
werden. 

Beispiel C: Rabatt 

Der Kunde erhalt Volumenrabatt nach Plan. Der Rabatt wird fur jede einzelne 
Transaktion gewahrt. Die Karte verwaltet keine Umsatzhistorie. Jede Transaktion 
ist in sich abgeschlossen. 
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Ziel: Der Rabattanspruch soil durch eine VAS-Applikation ausgewiesen 
werden. 

Beispiel D: Ausweisfunktion 

Eine Person kann durch Merkmale in der Karte gegenuber Dritten nachweisen, dali 
Berechtigung zu bestimmten Leistungen besteht. Die Zugehdrigkeit der Person 
zum Ausweis muR bei jeder Transaktion nachgewiesen werden (Lichtbild, PIN, 
Biometrik). Die Echtheit des Ausweises wird als Sicherheitsmerkmal 
herangezogen. 

Analog: Internet Zugang, Zugang Homebanking, Telefonkarte 

Ziel: Die Berechtigung soil durch eine VAS-Applikation nachgewiesen 
werden. 

Beispiel E: Werteinheiten 

Werteinheiten werden erworben und durch ein- oder mehrmalige Nutzung 
verbraucht. Pro Transaktion verringert sich der Wert um eine oder mehrere 
Einheiten. Die Nutzungsberechtigung ist ubertragbar und kann Einschrankungen 
fQr die Nutzung beinhalten. 

Analog: Einzelfahrschein, Streifenfahrschein, Abo-Konzertkarte, Squash- 
Zehnerkarte, Kino-Ticket, Telefoneinheiten 

Ziel: Durch eine VAS-Applikation soil die Abwicklung rationalisiert werden. 
Beispiel F: Nutzungsabrechnung 
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Die Nutzung einer Leistung wird nach Zeit, HSufigkeit Oder Menge registriert und 
nach Tarifplan abgerechnet. Im voraus ist nicht bekannt, in welchem Umfang die 
Leistung abgerufen wird. 

Analog: Verzehrbon, Kurzzeitparkschein 

Ziel: Durch eine VAS-Applikation soli die Abrechnung nach Tarif ermSglicht 
werden. Die jeweils aktuell ben5tigten Abrechnungsdaten sollen im VAS- 
Container gespeichert sein. 

Beispiel G: Merkzettel (Mobiler Datenspeicher) 

Diese Applikation ermdglicht die Obergabe von Daten des Karteninhabers an den 
VAS-Provider. Dadurch werden AblSufe automatisiert, die derzeit noch manuell 
erfolgen. Aus diesen Daten ISftt sich kein geldwerter Gegenwert ableiten. 

Analog: AusfQIIen von Lottoscheinen, Einkaufszettel, Kassenzettel, 
Telefonregister 

Ziel: Ein VAS-Provider soli die Daten der Karte entnehmen und so den 
entsprechenden Dienst direkt erbringen kflnnen (z.B. Telefonverbindung 
herstellen, gewOnschte Waren zusammenstellen, elektronisch den 
Lottoschein ausfQIIen und erfassen). Die Daten kdnnen sowohl 
kurzfristig als auch langfristig in der Karte gespeichert werden. 

Nach diesen Beispielen fur Intraservices sollen nun einige Beispiele fur 
Interservices folgen. 

Ein Interservice entsteht immer dann, wenn an einem Dienst mehrere VAS- 
Provider beteiligt sind. Dies ist untrennbar damit verbunden, daft Daten den 
Bereich eines VAS-Provider veriassen. Heute geschieht dies Qber 
Bescheinigungen auf Papier. 
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Beispiel A: Fahrpreiserstattung 

Ein Kaufhaus erstattet einem Kunden den Fahrschein eines OPNV-Unternehmens 
filr die Fahrt zum Kaufhaus. Der Kunde muR dem Kaufhaus den Einzelfahrschein 
voriegen. Das Kaufhaus vermerkt auf dem Fahrschein, daft er erstattet wurde. 
Eventuell bekommt das Kaufhaus seinerseits einen Teil der Erstattung an den 
Kunden vom Verkehrsunternehmen zuruck. 

Ziel: Der Erstattungsvorgang soli elektronisch abgewickelt werden. 
Beispiel B: Fahrgutschein 

Ein Kaufhaus erstattet dem Kunden beim Warenkauf die Kosten fur eine Heimfahrt, 
indem ein Gutschein ausgestellt wird. Der Kunde erhalt an einem 
Fahrkartenschalter ein Ticket des OPNV bzw. zahlt einen geringeren Preis fur das 
Ticket. Der Verkehrsbetrieb rechnet den Gutschein mit dem Kaufhaus ab. 

Ziel: Abbildung der Mechanismen durch VAS-Applikationen mit elektronischer 
Abrechnung zwischen Handel und OPNV. 

Beispiel C: Kundenparkplatz 

Ein Kaufhaus eretattet dem Kunden einen Teil der ParkgebQhren bei Benutzung 
eines bestimmten Parkhauses. Das Parkhaus wird durch ein unabhangiges 
Unternehmen betrieben und erhalt vom Kaufhaus eine geldwerte VergQtung fur 
jede Kundengutschrift. 

Ziel: Abbildung der Mechanismen durch VAS-Applikationen mit elektronischer 
Abrechnung zwischen Handel und Parkhaus. 



Beispiel D: Multilaterales Bonusprogramm 
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Eine Gruppe von Handelsunternehmen und Dienstleistern einigt sich auf ein 
gemeinsames Bonusprogramm. 

Ziel: Jeder Partner kann Bonuspunkte auf einem gemeinsamen Konto auf der 
Karte gutschreiben oder verguten. Die Abrechnung der Leistungen 
zwischen den Partnern erfolgt durch das Hintergrundsystem. 

Beispiel E: Anerkennung von Bonuspunkten zwischen Dienstleistern 

Jeder Dienstleister betreibt ein eigenes Bonusprogramm, hat aber Absprachen mit 
anderen, gesammelte Punkte anzuerkennen. Bekannte Beispiele sind Absprachen 
zwischen Autovermietem und Fluggesellschaften zum Sammeln von „Meilen". 

Ziel: UnterstOtzung der Obertragung von Bonuspunkten durch die Karte. 

Jeder VAS-Provider soli zunachst seine Punkte fur sich sammeln, ohne 
dali ein anderer eingreifen kann. Fur die Obertragung sollen sichere 
Mechanismen bereitgestellt werden. 

Beispiel F: Nachttaxi 

Durch einen Fahrausweis des OPNV wird gleichzeitig die Berechtigung zur Fahrt 
im Sammeltaxi (z.B. nach 22.00 Uhr) erworben. Das Taxiuntemehmen muli zur 
Abrechnung nachweisen, dad der Fahrausweis vorgelegen hat. Die 
Inanspruchnahme des Taxis wird auf der Karte vermerkt, urn MiRbrauch zu 
unterbinden. 

Ziel: Die VAS-Applikation soil die Inanspruchnahme, Kontrolle und 
Verrechung dieses Dienstes ernruJglichen. 

Im folgenden soli der Aufbau der erfindungsgemaften Chipkarte naher beschrieben 
werden. 
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Die Mikroprozessor-Chipkarte mit VAS-Funktionalitat enthait Jnsbesondere den 
VAS-Container. 

5 Der VAS-Container ist eine eigenstandige Anwendung und existiert entweder 
alleine Oder auch parallel neben anderen Applikationen auf der zugrundeliegenden 
Kartenplattform. Der VAS-Container ist vollstandig durch sich selbst definiert und 
allein funktionsfahig. Er kann ohne die in der Regel auf der gleichen Karte 
vorhandene Zahlungsfunktion betrieben werden. Insbesondere wird fOr den VAS- 

10 Container eine unabhangige Sicherheitsarchitektur definiert, so dali VAS- 
Applikationen eigenstandige Sicherheitsfunktionen verwenden kOnnen. 

Teil der Value Added Services sind Transaktionen durch den Kunden, die an 
Terminals der VAS-Provider durchgefOhrt werden. Der VAS-Provider hat ein 

15 Interesse, diese Transaktionen zu verfolgen, sei es zum Zweck der 
SystemGberwachung oder sei es zur Sammlung von statistischen und anderen 
Daten. Zur Optimierung und Vereinheitlichung der Datenstrukturen in der Karte 
wird von der Verwendung applikationsspezifischer Identifikationen abgeraten und 
die Nutzung einer systemweit eindeutigen VAS-Container ID empfohlen. Diese 

20 Nummer kann vom VAS-Provider zur Realisierung der o.g. Funktionen benutzt 
werden, und sie befreit ihn von der BQrde, eigene Nummernkreise zu verwalten. 

Die Sicherheitsarchitektur des VAS-Containers verwendet diese systemweit 
eindeutige ID zur Ableitung kartenspezifischer Schlussel. Die Venwendung der 
25 kartenspezifischen Nummer ware im Prinzip moglich, wird aber vorzugsweise nicht 
verwendet, da, falls der VAS-Container auf unterschiedlichen Plattformen 
implementiert wird, diese unter Umstanden kollidierende Nummernkreise 
verwenden. 

30 Die VAS-Container ID wird vom System Operator vergeben und durch den 
Kartenissuer bei der Erzeugung des VAS-Containers eingebracht. Sie wird mit dem 
LOschen des VAS-Containers vernichtet und damit aus dem System entfernt. Ein 
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VAS-Container gilt ats geldscht, wenn er keine VAS-Applikationen enthalt und die 
VAS-Container ID entfernt ist. 

Bei einer GesamtQbertragung des VAS-Containers von einer alten in eine neue 
Karte wird die VAS-Container ID zusammen mit den VAS-Applikationen 
transferiert. Dieser Transfer entspricht einem Verschieben des VAS-Containers aus 
der alten in die neue Karte. Die alte Karte enthalt nach diesem Vorgang keinen 
VAS-Container mehr. Der in der neuen Karte vorhandene VAS-Container wird bei 
dieser Operation Qberschrieben und damit geldscht Da die VAS-Container ID von 
der alten auf die neue Karte Qbertragen wird, ist in den Hintergrundsystemen der 
VAS-Provider keine Umwandlung der Bezugsnummem erforderiich. 

Einzelne VAS-Applikationen konnen nur unter der Kontrolle des jeweiligen VAS- 
Providers zwischen zwei verschiedenen VAS-Containern verschoben werden. Bei 
dieser Funktion andert sich die Zuordnung zwischen VAS-Container ID und VAS- 
Applikation, was u.U. im Hintergrundsystem des VAS-Providers vermerkt werden 
mud. 

Der VAS-Container enthalt keine personenbezogenen Merkmaie. VAS- 
Applikationen konnen personenbezogene Daten enthalten, der Umfang sollte 
jedoch aus Datenschutzgriinden und zur besseren Speicherausnutzung auf ein 
Minimum beschrankt werden. VAS-Applikationen sollen, falls erforderiich, 
personenbezogene Daten im Hintergrundsystem speichem und die Zuordnung zur 
Karte uber die VAS-Container ID hersteilen. 

Ein wesentliches Merkmal des VAS-Containers ist die UnterstQtzung von 
Interservices. Interservices erfordern Zugriff auf gemeinsame Daten, Obertragung 
von Leistungsansprilchen und die Abrechnung von Leistungen zwischen 
verschiedenen Partnern. Der VAS-Container muli dieses ermoglichen und 
trotzdem die Sicherheit der Applikationen im Intraservice gewahrleisten. 
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Sogenannte Intraservice VAS-Applikationen sind Applikationen, die unter der 
exklusiven Kontrolle des VAS-Providers betrieben werden. Der VAS-Provider 
definiert die Sicherheit seiner Applikation unabhangig von einer externen Stelle. 
Ohne Weitergabe der SchlOssel kann keine exteme Partei VAS-Daten verandern. 

Zur effizienten Abwicklung von Interservices mQssen die Partner auf gemeinsame 
Daten zugreifen konnen. Der gemeinsame Zugriff auf die Daten ist Ober abgestufte 
Sicherheitsmechanismen realisiert. 

Die erste Stufe des gemeinsamen Zugriffs erfolgt ausschlieftlich Uber bffentliche 
Transferfelder. VAS-Provider kdnnen Ober diese Felder Daten austauschen, ohne 
gegenseitig die Applikationen und SchlOssel kennen zu mOssen. Lediglich zum 
Schreiben von Daten in die Transferfelder mQssen die Terminals uber geeignete 
SchlOssel verfOgen, nicht aber zum Lesen. Lesen darf jeder ohne Einschrankung. 
Der Datenaustausch kann in beiden Richtungen zwischen VAS-Provider und 
Partner erfolgen, wenn jeder Ober seinen SchlOssel zum Schreiben verfOgt. Die 
Transferdaten konnen aus einer Intraservice VAS-Applikation des VAS-Provider 
erzeugt werden oder umgekehrt kann der VAS-Provider Daten aus dem 
Transferfeld in seine Intraservice VAS-Applikation hereinnehmen. 

Die zweite Stufe ist das Entwerten von Werteinheiten, die durch VAS-Daten 
verkSrpert werden. Ein VAS-Provider bringt Werteinheiten in die VAS-Daten mit 
einem speziellen SchlOssel zum Schreiben ein. Die Werteinheiten konnen durch 
Interservice Partner abgenutzt werden, die Ober einen SchlOssel zum Entwerten 
verfOgen, den sie vom gesamtverantwortlichen VAS-Provider bekommen. In dieser 
Stufe greifen Partner mit unterschiedlichen Rechten auf nicht-offentliche VAS- 
Daten zu. 

Die dritte Stufe ist der direkte schreibende Zugriff auf die VAS-Daten durch alle 
beteiligten Interservice Partner. Diese Methode erfordert ein entsprechendes MaB 
an Vertrauen zwischen den Parteien, da uneingeschrankt VAS-Daten verSndert 
werden konnen. 
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Das Transferfeld dient als Koppelglied zwischen VAS-Applikationen. Daten im 
Transferfeld werden von den VAS-Applikationen im VAS-Container erzeugt. Daten 
konnen auch direkt im Transferfeld angelegt werden, wenn der Erzeuger keine 
eigene VAS-Applikation im VAS-Container betreibt. 

Das Transferfeld steht prinzipiell alien Applikationen zur VerfOgung, schreiben darf 
aber nur wer Ober eine Berechtigung (SchlQssel) dafQr verfQgt. Nur nach den 
Regeln, d.h. den Rules und Regulations R&R, dazu berechtigte Empfanger dQrfen 
Daten aus dem Transferfeld entnehmen. Der Empfanger prtift das Vorhandensein 
von fur ihn bestimmten Transferdaten und entnimmt sie zur Verarbeitung im 
eigenen System. 

Urn die Manipulation von Transferdaten im offentlichen Austausch zu verhindern, 
bringt der Erzeuger ein Echtheitsmerkmal und der VAS-Container eine 
Sequenznummer ein. Mit diesen Elementen wird die Einmaligkeit einer 
Transfernachricht sichergestellt und der Ursprung der Daten nachgewiesen. 

Bei Bedarf wird der Empfanger der Transferdaten vom Erzeuger mit der 
Moglichkeit ausgeriistet, eine Echtheitspriifung durchzufiihren. Wird dies nicht 
gewunscht, kann die Akzeptanz der Daten auch nach Treu und Glauben erfolgen; 
das Echtheitsmerkmal wird dann u.U. erst bei einer Abrechnung im 
Hintergrundsystem des erzeugenden VAS-Provider gepruft. 

Die Daten kdnnen aus dem Transferfeld nur einmalig mit Erhalt eines 
Echtheitsmerkmals entnommen werden. Bei der Entnahme werden die Daten 
markiert und verbleiben (als Kopie) im Transferfeld. Damit kann auch nach der 
Entnahme der Daten filr einen bestimmten Zeitraum der Transfervorgang 
nachgewiesen werden. 

Daten im Transferfeld tragen ein Verfallsdatum. Verfallene Daten kdnnen bei 
Bedarf von beliebigen Applikationen uberschrieben werden. Die Daten im 
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Transferfeld kfinnen bei der Entnahme markiert werden, so daft sie zum sofortigen 
Uberschreiben freigegeben sind. Sollte sich der Transferspeicher dennoch 
vollstandig fallen, bevor ein Transferdatensatz verfailt, so muft der Karteninhaber 
am Serviceterminal nicht mehr bendtigte Eintrage Iflschen. 

FQr die Modellierung von VAS-Applikationen werden 3 Operationen deflniert. Diese 
Operationen wirken auf die VAS-Daten. Laden und Loschen von Applikationen sind 
Funktionen des VAS-Containers und werden in den folgenden Absatzen nicht 
betrachtet. 

Erwerben Allgemein das Erwerben eines Leistungsanspruchs und die Ablage 
eines Nachweises in den VAS-Daten einer VAS-Applikation. 

Entwerten Allgemein das Einl6sen des Anspruchs ohne, mit volistandigem oder 
mit teilweisem Verbrauch von VAS-Daten einer Applikation. Der 
Vorgang erzeugt eine elektronische Quittung, die im Transferfeld 
abgelegt wird. Diese Quittung tragt ein sinnvolles Verfallsdatum, zu 
dem sie aus dem Transferspeicher gelfischt werden kann. 

Entnehmen Allgemein die Entnahme der elektronischen Quittung aus einem 
Transferfeld zur weiteren Verarbeitung (z.B. Hintergrundsystem). Eine 
Kopie der Quittung verbleibt und dient als Nachweis des 
„Entwertens 4 \ 

„Erwerben w von VAS-Daten kann nur durch den jeweiligen VAS-Provider erfolgen. 
„Entwerten H von VAS-Daten kann nur durch den VAS-Provider erfolgen, der sie mit 
^Erwerben" erzeugte oder durch einen Interservice Partner, den der VAS-Provider 
dazu ermachtigt. n Entnehmen tt kann auch durch jeden anderen VAS-Provider 
erfolgen. Bei einem Interservice ohne gleichberechtigten Zugriff auf die VAS-Daten 
Ifist der Partner den ZustandsQbergang „Entnehmen M aus. Die so gewonnene 
elektronische Quittung kann dann uber den System Operator und das 
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Hintergrundsystem des VAS-Provider abgerechnet werden. „Erwerben tt und 
^Entwerten" kann in einem Schritt erfolgen. 



VAS-Applikationen mit gemeinsamen Merkmalen lassen sich in Klassen 
5 unterteilen. Diese Klassen bilden die Basis fQr Datenstrukturen im VAS-Container. 
Der VAS-Provider wShlt bei der Implementation seiner Anwendung eine 
Applikationsklasse aus. 

Es werden dabei folgende Applikationsklassen deflniert: 

10 

• Punktespeicher 

• Ticket 

• Ausweis 

• Gutschein 

15 • Datenspeicher 

Punktespeicher bezeichnet eine Applikationsklasse, in der ein Konto von 
Punktwerten verwaltet wird. Auf das Punktekonto konnen Werte aufgebucht und 
abgezogen werden. Das Aufbuchen von Werten erfolgt durch den VAS-Provider, 
20 indem der Speicher mit dem neuen Kontostand beschrieben wird. Das Abbuchen 
von Werten erfolgt durch die „Entwerten"-Operation, wobei als Beleg eine 
elektronische Quittung im Transferspeicher abgelegt wird. Der Zugriff auf die 
beiden Funktionen ist durch zwei unterschiedliche ZugriffsschlQssel realisiert. 

25 Ticket bezeichnet eine Applikationsklasse, in der ein Wertfeld existiert, welches 
einmalig oder mehrmalig entwertet und damit verbraucht wird.Das Aufbuchen von 
Werten in der Applikationsklasse Ticket erfolgt einmalig. 

Ausweis bezeichnet eine Applikationsklasse, bei der die VAS-Daten den Nachweis 
30 einer Berechtigung beinhalten. Der Nachweis wird in der Regel nicht durch 
Nutzung verbraucht; er wird allerdings nach einem definierten Kriterium, z.B. nach 
zeitlichem Verfall, ungQItig. Je nach Auspragung der Applikation wird die Echtheit 
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des Ausweises (z.B. Anwohnerparkschein) oder die Vortage eines Ausweises 
dokumentiert (z.B. Sammeltaxifahrt mit Monatsfahrschein: Erzeugen einer 
elektronischen Quittung durch die Karte. Die Quittung wird vom Taxiuntemehmen 
beim OPNV eingereicht und anteilig verrechnet). Optional kann die Nutzung des 
5 Ausweises durch elektronische Quittungen im Transferspeicher der Karte 
dokumentiert werden. 

Gutschein bezeichnet eine Applikationsklasse, bei der Leistungsanspruche (in der 
Regel kurzfristig) in der Karte zwischengespeichert werden. Diese elektronischen 

10 Gutscheine werden ausschlie&lich im Transferspeicher des VAS-Containers 
gespeichert. Die den Gutschein verwertende Applikation ist in der Regel eine 
andere als die erzeugende Anwendung. Die Entnahme des Gutscheins aus dem 
Transferspeicher ist nur einmalig moglich und wird durch die Karte dokumentiert. 
Ein vom VAS-Container erzeugtes Echtheitsmerkmal kann bei der Abrechnung im 

15 Hintergrundsystem benutzt werden. 



Datenspeicher bezeichnet eine Applikationsklasse, bei der ein VAS-Provider Daten 
im VAS-Container speichert, die fur den Kunden einen zusatzlichen Service bieten 
(z.B. Letztes Menu in Fast-Food Restaurant, Letzte Lottozahlen, Service 
20 Praferenzen, Vorschlagslisten). Die Daten sind nur zur Information und stellen 
keinen Leistungsanspruch gegen den VAS-Provider dar. Der Zugriff auf die Daten 
wird vom VAS-Provider gesteuert. 

Jede Applikationsklasse zeichnet sich durch einen typischen Nutzungszyklus aus. 
25 Die folgende Tabelle zeigt, in welcher Frequenz die drei oben definierten 
Operationen auf die VAS-Daten der Applikationsklasse angewendet werden (Zur 
Beachtung: „Erwerben" bedeutet nicht Applikation laden" und ..Entnehmen" 
bedeutet nicht Applikation Idschen"). 
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Punkte- 
speicher 


Ticket 


Ausweis 


Gutschein 


Daten- 
speicher 


Erwerben 


Mehrfach 


Einfach 


Einfach 


Einfach 


Mehrfach *** 


Entwerten 


Mehrfach 


Mehrfach 


Mehrfach 


Einfach 


Nie 


Entnehmen 


Mehrfach 


Mehrfach 


Mehrfach 


Einfach 


Nie 






Tabelle 1 - 


Nutzungszyklus 







*** In der Applikationsklasse „Datenspeicher" wird nicht ein Anspruch erworben, 
5 sondem die Applikation tragt lediglich Daten in die Applikation ein. 

Fig. 4 veranschaulicht die oben aufgefuhrten Applikationsklassen und Operationen 
durch ein Transaktionsmodell. 



10 Im folgenden soli auf die Sicherheitsarchitektur der erfindungsgemalien Chipkarte 
naher eingegangen werden. Zur Gewahrleistung der Sicherheit werden die 
folgenden SchlOssel defmiert: 



Name 


Ort 


Inhaber 


Beschreibung 


Kso 


VAS- 
Container 


System 
Operator 


Schlussel fur Verwaltung des VAS- 
Containers 


Kaut 


VAS- 
Container 


System 
Operator 


SchlQssel fur Authentifizierung des VAS- 
Containers 


Ksig VASC 


VAS- 
Container 


System 
Operator 


SchlQssel zum Signieren der 
Transaktionsdaten 


KGKqec 


VAS- 
Container 


System 
Operator 


SchlQssel fur die Ableitung des 
KGKdfc pix 


Klvasp 


VAS- 

Applikation 


VAS-Provider 


SchlQssel fur den Schreibzugriff auf VAS- 
Daten 


Krvasp 


VAS- 

Applikation 


VAS-Provider 


Schlussel fur den Lesezugriff auf VAS- 
Daten 


KGK DEC pi X 


VAS- 
Provider 


VAS-Provider 


Schlussel fur die Ableitung des K 0EC 


Kqec 


Handler- 
terminal 


VAS-Provider 


SchlQssel fQr Authentifizierung des 
Handlerterminals 



Tabelle 2 - SchlQsseltibersicht 



15 
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Die Sicherheitsarchitektur basiert auf dem Lebenszyklus von VAS-Container bzw. 
VAS-Applikationen und ist nach der Verantwortlichkeit der beteiligten Instanzen 
geschichtet. Eine eriauterende schematische Darstellung ist in Fig. 5 gezeigt 

5 Nachfolgend einige Eriauterungen zur Struktur des VAS-Containers sowie der 
darauf aufgebrachten Applikationen. 

Der VAS-Container sowie VAS-spezifische Erganzungskommandos werden 
entweder vom Issuer zusammen mit anderen Nicht-VAS-Applikationen auf die 
10 Karte gebracht oder spatestens an einem Serviceterminal durch einen autorisierten 
VAS-Provider auf einer bestehenden Kartenplattform integriert. 

Fur die zweite Mdglichkeit kann der folgende Mechanismus Verwendung finden: 
Der System Operator verabredet mit dem Issuer einen temporaren Schlussel K so *. 

15 Der Issuer ciffnet die Karte mit seinem nur ihm bekannten Schlussel, legt die 
Dateien des VAS-Container an und schreibt insbesondere den K so * in das 
DF_VAS. Der System Operator kann dann zu einem spateren Zeitpunkt (z.B. die 
Karte kommt zum ersten Mai mit einem Serviceterminal in Bertihrung) den 
Schlussel K so * durch seinen eigenen Schlussel K S o ersetzen, den dann nur er 

20 alleine kennt. Der System Operator kann nun weitere Daten, wie z.B. den KGK DECf 
selbst eintragen oder im Falle einer Plattform mit dynamischer Speicherverwaltung 
Dateien fur VAS-Applikationen selbst erzeugen bzw. Iflschen. Damit ist 
sichergestellt, daft der Issuer nach der ersten Benutzung einer VAS-Karte keinen 
Zugriff mehr auf den VAS-Container hat und der System Operator lediglich Zugriff 

25 auf den VAS-Container. Da es mit anderen Applikationen keine gemeinsamen 
Datenstrukturen und keinerlei Datenaustausch gibt, ist die Sicherheitsarchitektur 
des VAS-Containers somit unabhangig von anderen auf der Kartenplattform 
vorhandenen Applikationen. 

30 In einer speziellen AusfQhrungsform der Erfindung soli jedoch von der ersten 
M&glichkeit Gebrauch gemacht werden: Der Issuer soli im Auftrag des System 
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Operator den VAS-Container inklusive aller SchlQssel auf die VAS-Karten 
aufbringen. 

Der VAS-Container besteht aus einer vorgegebenen Dateistruktur, vorgegebenen 
5 Zugriffsbedingungen (ACs) und einigen globalen Daten. Die globalen Daten 
enthalten u.a. den SchlQssel K so zum Laden bzw. LOschen von VAS-Applikationen. 
Ober diesen SchlQssel, den nur der System Operator kennt, wird sichergestellt, dafi 
nur zugelassene VAS-Applikationen geladen werden konnen. Die Karte verlangt 
dazu eine externe Authentifizierung des System Operators mit K so . 

10 

Wenn ein Karteninhaber an einem Serviceterminal eine VAS-Applikation laden 
mOchte, beauftragt der zustandige VAS-Provider den System Operator damit, dies 
fur ihn zu tun. Beim Laden der VAS-Applikation in den VAS-Container Qbergibt der 
VAS-Provider dem System Operator die SchlQssel K LV asp und K RVASP , die dieser mit 

15 in die Applikation eintragt. Durch den SchlQssel K LVA sp kann der VAS-Provider 
Daten der Applikation vor schreibendem Zugriff und zusStzlich interne Daten vor 
lesendem Zugriff schQtzen. Dazu verlangt die Karte eine externe Authentifizierung 
des VAS-Provider basierend auf K LVASP ; d.h. die Karte pruft aktiv die Echtheit des 
Terminals. Nach erfolgreicher AusfQhrung dieser Funktion wird einem Terminal der 

20 schreibende Zugriff auf eine VAS-Applikation und der lesende Zugriff auf interne 
VAS-Daten der Applikation erlaubt. Eine interne Authentifizierung, d.h. die Prufung 
der VAS-Applikation (und damit der Karte) auf Echtheit durch das Handlerterminal, 
kann optional erfolgen. Bei der Nutzung der VAS-Applikation durch den 
Karteninhaber kOnnen an beliebigen Terminals, die Qber den SchlQssel K LVA sp 

25 verfQgen, diese intemen VAS-Daten in die Applikation geschrieben bzw. verandert 
werden. Die Funktion „Erwerben M stQtzt sich deshalb auf einen UPDATE RECORD 
Befehl, dem eine externe Authentifizierung mit dem SchlQssel K LVASP vorausgehen 
muR. 

30 Der lesende Zugriff auf alle nicht intemen Daten der VAS-Applikation ist nur 
erlaubt, wenn eine vorherige externe Authentifizierung durch K RVASP oder durch K so 
oder durch die korrekte Eingabe einer PIN oder eines Paliwortes durch den 
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System Operator erfolgt. Der PIN-/PalJwort-geschQtzte Zugriff wird vorgesehen, urn 
Daten fur den Karteninhaber an Terminals Oder am Wallet einsehbar zu machen. 
Der Karteninhaber hat an einem Serviceterminal die Wahl, fur alle Applikationen 
gleichzeitig einen PIN-/Paliwort-Schutz fur das Lesen der Wert- bzw. Statusdaten 
5 zu aktivieren bzw. zu deaktivieren. 

Zu den globalen Daten des VAS-Container gehcirt ein SchlQssel K sig _ V asc zum 
Signieren von entnommenen Daten aus dem Transferfeld. Anhand der Signatur 
kann die Unversehrtheit dieser Transaktionsdaten nachgeprtift werden, wenn sie 

10 manipulationsgesichert zwischen Interservice Partnern zur gegenseitigen 
Verrechnung Obertragen werden mQssen. ZusStzlich zu einer optional durch die 
Interservice Partner eingebrachten Signatur wird fQr Datensatze, die die Karte mit 
der Operation „Entnehmen" ausgibt, eine Signatur basierend auf K SIG V asc un d 
einem vom VAS-Container verwalteten TransaktionszShler hinzugefugt. Da zwar 

15 Lesen des Transferfeldes jedem erlaubt ist, jedoch die Signatur der Karte mit 
Ksig vasc nur beim Aufruf der Operation JEntnehmen" erzeugt wird (und dies kann 
nur einmalig geschehen), wird die unzuiassige doppelte Abrechnung von 
Gutscheinen erkannt. Jeder Interservice Partner kann sich vom System Operator 
die Echtheit und Einmaligkeit eines entnommenen Gutscheins bestatigen lassen. 

20 AuRerdem kann vom System Operator durch PrQfung der Signatur die Echtheit des 
VAS-Containers nachgewiesen werden. 

Sollte eine Kartenplattform asymmetrische SchlQsselverfahren unterstQtzen, kann 
als K SIG j/asc auch ein privater (geheimer) SchlQssel innerhalb der Karte zum 
25 Signieren herangezogen oder ein solcher SchlQssel aus einem privaten Key 
Generating Key abgeleitet werden. Die VAS-Provider kOnnten in diesem Fall 
fiffentliche (nicht geheime) SchlQssel zur eigenen PrQfung der Signatur 
heranziehen, ohne den System Operator konsultieren zu mussen. 

30 Zu den Daten des VAS-Container gehfirt ein globaler Key Generating Key KGKo ECl 
der fur alle Terminals aller VAS-Provider zur BerechtigungsprQfung der Operation 
„Entwerten u den ZugriffsschlQssel Kqec erzeugen kann (mehr zur 
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Schlusselableitung und PrGfung folgt spater). An das Entwerten von geldwerten 
Daten werden nicht die gleichen Sicherheitsmaftstabe wie an das Laden bzw. 
Erwerben eines Anspruchs gesteilt. Es genQgt hier, anstelle eines 
applikationseigenen Schlussels einen globalen SchlQssel zu verwenden. Dieser 
5 globale SchlQssel wird durch Ableitung zunachst in einen Applikationsschlussel 
Qberfuhrt und anschlieftend durch erneutes Ableiten zum TerminalschlusseL Dem 
VAS-Provider wird nur die applikationsspezifische Ableitung des globalen 
Schlussels zur Erstellung eigener TerminalschlQssel Qbermittelt. Dies wird 
nachfolgend kurz geschildert: 

10 

Wir bezeichnen mit mac(k v d) die Berechnung eines Message Authentication Code 
fur eine Nachricht d und einen DES-Schlussel k mittels DES. Falls die Nachricht 
nicht langer als 8 Bytes ist, entspricht dies der VerschlQsselung selbst (ICV=0 
vorausgesetzt). Wir bezeichnen mit macp(k,d) die Berechnung von mac(k, d) mit 
15 anschlieliender Angleichung der Paritdtsbits. Das Ergebnis k 1 = macp(k.d) ist 
wieder ein gdltiger DES-SchlQssel. 



Die Berechnung des applikationsspezifischen Terminalschlussels geschieht dann 
wie folgt: 

20 

1 . Jede Karte speichert einen SchlQssel 

der fUr alle Karten gleich ist und der das Geheimnis des System Operators ist. 
Der System Operator veranlafit, daft dieser Schlussel in die Karte personalisiert 
25 wird. 

Aus diesem Schlussel kOnnen sSmtliche VAS-Applikations- und 
TerminalschlQssel abgeleitet werden. 

30 2. Ein VAS-Provider mdchte eine VAS-Applikation A mit AID A =RIDv AS .PIX A 
einfQhren. Nun berechnet der System Operator aus dem Schlussel KGK DEC und 
der PIX den applikationsspezifischen SchlQssel 
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KGK DECt pix = macp(KGK D £c« P'X A ) 
und ubergibt diesen SchlQssel dem VAS-Provider. 

3. Dieser VAS-Provider leitet aus KGK DECPD( fur alle Terminals, die das 
5 TRANSFER-Kommando auf die VAS-Applikation A anwenden sollen, mit Hilfe 

ihrer Terminal ID ihre spezifischen SchlQssel ab: 

K DEC = macp(KGK 0ECP/x , Terminal ID) = 
macp(macp(KGK 0K , PIX A ), Terminal ID) 

10 Der VAS-Provider speichert diese SchlQssel in seinen Terminals. Sofern der 
VAS-Provider nicht selbst die Terminals betreibt, generiert er die SchlQssel und 
verteilt sie an die Betreiber der Terminals. 

4. Die VAS-Karte fQhrt das TRANSFER Kommando nur durch, wenn das 
15 Kommando ein vom Terminal erzeugtes Kryptogramm C enthSIt, das Qber 

bestimmte Daten data der Nachricht im Transferspeicher gebildet wird. Die Karte 
selbst kennt KGK DEC und bekommt von einem Terminal neben den Nutzdaten 
data und dem Kryptogramm C die Terminal ID sowie die PIX geschickt (bzw. die 
Karte kennt die PIX selbst, siehe hierzu auch die Beschreibung des Kommandos 
20 TRANSFER). Nun kann die Karte das Kryptogramm C Qber die Nutzdaten 
selbst berechnen: 



Die Karte vergleicht nun das selbst berechnete Kryptogramm C mit dem vom 
Terminal berechneten Kryptogramm C. Sind sie unterschiedlich, erfolgt ein 
Abbruch der Transaktion mit einer Fehlermeldung. Im Falle der 
30 Obereinstimmung wird die VAS-Karte das TRANSFER-Kommando ausfuhren. 



25 



mac(macp(macp(KGK D£C ,PIX), Terminal ID),data) = 
= mac(macp(KGK oeaP ,x, Terminal ID),data) = 
= mac(K DEC ,data) = 
= C 
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Die unterschiedlichen SicherheitsmaRstabe werden den unterschiedlichen 
Bauweisen von Serviceterminals bzw. Handlerterminals (zum Laden bzw. 
Erwerben) und einfachen Handlerterminals (zum Entwerten) gerecht. Ein Terminal 
muli sich zur AusfOhrung der „Entwerten w Operation gegenuber der Karte durch 

5 Kenntnis eines Schlussels K DEC authentisieren. Bei Kompromittierung des 
SchlQssels Ko EC kann der Angre'rfer lediglich die Funktionen dieses einen Terminals 
durchfuhren. Dieser Vorgang wird jedoch in der Karte protokolliert. Die 
Dokumentation enthait eine eindeutige Sequenznummer, die Entwertung und die 
Terminal ID. Die VAS-Applikationen nutzen die Sicherheitsdienste des VAS- 

10 Containers, urn den Zugriff auf VAS-Daten zu reglementieren. Die AusfOhrung von 
VAS spezifischen Funktionen wird durch die Definition von Zugriffsrechten auf 
berechtigte Parteien beschrankt 

Im allgemeinen mull es fur jede VAS-Applikation Sffentlich zugSngliche 
15 Datenbereiche (z.B. zum Auslesen von Werten mit einem Wallet) und private 
Datenbereiche des verantwortlichen VAS-Provider geben, die er vor dem Zugriff 
durch andere schOtzen kann (z.B. interne Verwaltungsdaten). 

Da Karten nach ISO 7816-4 fur einzelne Records von Elementary Files (EF) keinen 
20 differenzierten Zugriffsschutz bieten, mQssen mehrere Dateien, die jeweils einen 
Record enthalten, zur Darstellung unterschiedlicher Sichten auf eine VAS- 
Applikation verwendet werden. 

So laiit sich fur die Applikationsklassen Punktespeicher, Ticket, Ausweis und 
25 Datenspeicher differenzierter Zugriffsschutz durch die Aufteilung der VAS-Daten in 
vier Elementary Files realisieren, wie in Fig. 6 dargestellt. 

Die vier Elementary Files enthalten folgende Daten bzw. werden folgendermaden 
geschiltzt: 

30 
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Feld 


Inhalt 


Typfsche Nutzung 


Zugriffsschutz 


EF_KEY 


Enthait die 
SchlGssel 

Klvasp* Krvasp 
die nur der 
VAS-Provider 
kennl 

(Anmerkung: 
ProVAS- 
Appllkation 
und optional 
pro Karte 
vergibt der 
VAS-Provider 
jeweils ein 
SchlUsselpaar 

) 


Ein VAS-Provider muB sich mit 
KtvASP authentisieren, bevor er 
VAS-Daten schreiben darf in 
EFJNFO, EFJNTERNAL und 
EF VALUE bzw. bevor er Daten 
aus EFJNTERNAL lesen darf. 

Ein Terminal muft sich mit 
Krvasp authentisieren, bevor es 
VAS-Daten aus EF INFO, 
EFJ/ALUE lesen darf. 




EFJNFO 


Nicht interne 
Informationen 
Qber dieVAS- 
Applikation 


• Tlcketinformationen 

• Donusprogramm inTormauon 

• Ausweisinformationen 

• Parkschein Informationen 


Die Inhalte dieser Dateneinheit 
kflnnen nur vom VAS-Provider 
geschrieben (exteme 
Authentifizierung durch Kenntnis 
von Krvasp) werden. Lesen soil 
nur an Terminals, die Qber Kr V asp 
Oder K so verfOgen, mdglich sein, 
Oder der Karteninhaber gibt einen 
korrekten PIN ein. (DerPIN- 
Schutz kann von Karteninhaber 
deaktiviert werden.) 


EFJNTERNAL 


Interne Daten 

Har \/AC 

aer vao- 
Applikation 


Interne Zahler, Kontostande, 
Steuerinformationen, zusStzliche 
Keys fOr: 

• Bonusprogramme 

• Rabattstaffelungen 

• Verdeckte Ausweismerkmale 

• Codes 


Die Inhalte dieser Dateneinheit 
kdnnen nur vom VAS-Provider 
beschrieben und gelesen werden. 
Der Zugriffsschutz basiert auf ex- 
temer Authentifizierung durch 
Kenntnis von Klvasp- 


EFJ/ALUE 


Werteinheiten 

derVAS- 

Applikation 


Diese Dateneinheit enthait 
buchbare Werte einer VAS- 
Provider Applikation. 

• Kontostand 

• Restwert Fahrschein 

• Guthaben 

• Nutzungszahler 


Nur der VAS-Provider kann diese 
Werte explizit schreiben (exteme 
Authentifizierung durch Kenntnis 
von Klvasp). Implizit kann der Wert 
durch den Befehl w Entwertung M 
von einem Partner verringert 
werden, der zur AusfOhrung der 
Funktion durch den VAS-Provider 
berechtigt wurde (durch Signatur 
der Operation Entwertung mit 
Kn Fr ). Lesen wie bei EF INFO. 



Tabelle 3 • Obersicht Dateien 



Diese Struktur von Elementary Files (EF) unterstQtzt die gleichen differenzierten 
Zugriffsrechte fQr alle Applikationsklassen. 
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Indem nun gleichartige Applikationsklassen zu jeweils einer 
Implementierungsklasse, die Anzahl und GrdBe der Elementary Files festlegt, 
zusammengefaBt werden, laBt sich ein Speicherverschnitt durch unterschiedlichen 

5 Platzbedarf fur Applikationen minimieren. Die Applikationsklassen Punktespeicher 
und Ticket bendtigen die gleichen Resourcen EF_KEY, EFJNFO, EFJNTERNAL. 
EF_VALUE und werden daher zusammengefaBt zur Implementierungsklasse 
„DF_PT". Fur die Applikationsklassen Ausweis und Datenspeicher genOgen die 
Elementary Files EF_KEY und EFJNFO und werden daher zur 

10 Implementierungsklasse „DF_AD" zusammengefaBt. AnzahlmaBig betrachtet: Es 
gibt p Objekte der Implementierungsklasse DF_PT und a Objekte der 
Implementierungsklasse DF_AD, in die VAS-Applikationen der Applikationsklassen 
Punktespeicher und Ticket bzw. Ausweis und Datenspeicher geladen werden 
kfinnen. 



Speziell fur die Applikationsklasse Gutschein, die offentliche Lesezugriffe fur alle 
VAS-Teilnehmer zum gemeinsamen Datenaustausch enthalten soil, wird die 
Implementierungsklasse Transferfeld verwendet. Schreibzugriffe sind 
ausschlieBlich indirekt durch die Anwendung des TRANSFER Befehls moglich, der 
20 eine Signatur mit einem korrekten K DEC verlangt. Diese Implementierungsklasse 
besteht aus genau einem Eintrag im Elementary File EF_TRANSFER, das zu den 
globalen Daten des VAS-Container gehort. Die Objekte dieser Klasse sind Records 
in dieser Datei. Wir nennen diese Implementierungsklasse auch „EF_TRANSFER". 

25 Es gibt die in Fig. 7 dargestellten Implementierungsklassen innerhalb des VAS- 
Container. Diese Implementierungsklassen bilden das Speichermodell des VAS- 



15 



Container. 



Die Bereitstellung des Speichermodells kann auf zwei Arten erfolgen. Die Wahl 
30 hangt von der Kartenplattform ab: 
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- Feste Partitioniervng des Speicherbereichs fQrden VAS-Container: 

Fur die Implementierungsklassen DF_PT und DF_AD wird vom Issuer jeweils 
ihre maximale Anzahl p bzw. a von Objekten festgelegt und diese vom Issuer 
auf die Karte mit CREATE FILE Befehlen geladen. Die Objekte notieren wir mit 
DF_PT| bzw. DF^ADi. VAS-Applikationen kOnnen zu einem spSteren Zeitpunkt in 
freie, also nicht von anderen VAS-Applikationen belegte Objekte geladen 
werden. Zum Laden bzw. Loschen von VAS-Applikationen sind danh nur 
UPDATE RECORD Befehle notwendig. 

Der Issuer legt also die Anzahl von mOglichen Objekten der beiden 
Implementierungsklassen nach seinen eigenen Bedtirfnissen fest; dies kann 
eventuell nicht mit dem tatsSchlichen VAS-Nutzungsverhalten des 
Karteninhabers ubereinstimmen. Die Aufteilung wird Qber den gesamten 
Lebenszyklus der Karte beibehalten. Eine VAS-Applikation wird in ein Objekt 
geladen, das von einer geeigneten Implementierungsklasse ist. So kann z.B. 
eine VAS-Applikation, die einen Ausweis darstellt, auch in einem Objekt der 
Implementierungsklasse DF_PT untergebracht werden, wenn keine Objekte der 
Implementierungsklasse DF_AD (mehr) zur Verfugung stehen. Die Zuweisung 
einer VAS-Applikation zu einem Objekt erfolgt durch den Eintrag eines Tripels 
(PIX der VAS-Applikation, FID des belegten Objektes, Klartextname der 
Applikation) in die globale Datei EFJDIR des VAS-Container. Das Entfernen der 
Applikation entspricht dem Entfernen dieses Tripels aus EF_DIR und dem 
zerstorenden Lesen (durch UPDATE RECORD Befehle) des von der Applikation 
belegten Speichers. 

Diese Variante findet Verwendung bei Kartenplattformen, die keine dynamische 
Erzeugung bzw. Loschung von DF/EF Strukturen unterstutzen. 

- Dynamisches Anlegen von Objekten der Implementierungsklasse: 
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FQr jede zu ladende VAS-Applikation werden mit CREATE FILE Befehlen die fQr 
die zugrundeliegende Implementierungsklasse bendtigten Dateien angelegt. 
Beim Ldschen der VAS-Applikation wird die von ihr belegte DF/EF vollstandig 
aus der Karte entfemt und der Speicherplatz freigegeben. Die maximale Anzahl 
5 von Objekten von Implementierungsklassen ist hier nicht explizit vom Issuer 
festzulegen und hangt nur vom zur VerfQgung stehenden Speicherplatz der 
Karte ab. 

Diese Variante erfordert eine dynamische Speicherverwaltung durch das 
10 Kartenbetriebssystem. 

Im vorliegenden Ausfuhrungsbeispiel gehen wir von der ersten Variante aus, da die 
zweite erhohte Anforderungen an die zur VerfQgung stehende Kartenplattform 
stellt. Steht eine dynamische Speicherverwaltung jedoch zur VerfQgung und ist 
15 sichergestellt, dali sich durch das dynamische Anlegen von Objekten mehr 
Speicher sparen laRt als die Verwaltung kostet, dann kann das bestehende 
Konzept Qbernommen werden und bietet dem Karteninhaber mehr Flexibilitat. 

Im folgenden werden die Datenstrukturen und Kommandos vorgestellt, mit denen 
20 sich der VAS-Container und die Funktionalitat der VAS-Kundenkarte gegenQber 
anderen Systemkomponenten realisieren lassen. Aulierdem werden fQr typische 
Geschaftsfaile VAS-Operationen festgelegt, die die jeweilige Interaktion zwischen 
VAS-Container und Terminal beschreiben. 

25 Fur die Implementierung wird von folgenden Voraussetzungen ausgegangen: 

• An einem Handlerterminal stellt jede Karte, unabhangig von der Plattform, die 
gleiche Daten- und Kommandoschnittstelle zur VerfQgung. Die erforderlichen 
Kommandos sind daher in ihrer Kodierung eindeutig beschrieben. 

30 

• Serviceterminals sind fahig, die Kartenplattform zu erkennen. Die Funktionalitat 
kann daher durch spezifische Kommandos der Plattform erreicht werden. Diese 
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VorgSnge sind daher teilweise informell beschrieben. Wie diese Funktion 
bereitgestellt wird ist dem Kartenhersteller freigestellt. 



In Fig. 7 werden hierzu schematisch verschiedene Implementierungsklassen des 
5 VAS-Containers dargestellt. Fig. 8 zeigt schematisch die Dateistruktur des VAS- 
Containers, Fig. 9 zeigt schematisch die Dateistruktur der Implementierungsklasse 
DF_PT, Fig. 10 die Dateistruktur der Implementierungsklasse DF_AD. 

Der Zugriff auf die Dateien des VAS-Container wird explizit durch folgende Access 
10 Conditions (AC) eingeschrankt: 



Datei 


ADMIN 


Lesezugriff 


Schreibzugriff 


DF VAS 


K so 


NEV 


NEV 


EF ID 


K so 


ALW 


Kso 


EF DIR 


K so 


ALW 


Kso 


globale KEYs 


K so 


NEV 


K so 


PIN 


K so 


NEV 


Kso 


EF VERSION 


K so 


ALW 


K SO 










EF SEQ 


Kso 


ALW 


Kso 


EF TRANSFER 


K so 


ALW 


Kso 










DF_X 

(X=PT, PT 0 ,AD 1t ...,AD a 

) 


K s0 


NEV 


NEV 


EF KEY 


Kso 


NEV 


Kso 


EFJNFO 


K so 


PIN Oder Kr VAS p 
oder K RO 


Klvasp 


EF INTERNAL 


Kso 


Klvasp 


Klvasp 


EF_VALUE 


Kso 


PIN Oder Krvasp 
oder Ksq 


Klvasp 



Tabeile 4 - Zugriffsbedingungen 



Dabei haben die AC folgende Bedeutung: 

15 

• ALW (Always) = Der Zugriff des Kommandos auf die Datei ist immer erlaubt. 

• NEV (Never) = Der Zugriff des Kommandos auf die Datei ist nie erlaubt. 
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• K so = Vor Zugriff muli externe Authentifizierung des System Operator mit dem 
Schlussel K so erfolgen. 

• K LVASP = Vor Zugriff muli externe Authentifizierung des VAS-Provider mit dem 
Schlussel K LVASP erfolgen. 

5 • K R vasp = Vor Zugriff mull externe Authentifizierung eines vom VAS-Provider 
autorisierten Terminals mit dem SchlOssel K RVASP erfolgen. 

• PIN = Vor Zugriff muli die korrekte PIN durch den Karteninhaber eingegeben 
werden und im Klartext mit dem Kommando VERIFY an die Karte geschickt 
werden. 

10 • PIN oder Krvasp^ k S o = v ° r Zugriff muli entweder die korrekte PIN durch den 
Karteninhaber eingegeben werden, oder es erfolgt eine externe 
Authentifizierung durch den VAS-Provider mit K RVA sp oder durch den System 
Operator mit K so . 

15 Dabei ist anzumerken, dali die Oder-VerknOpfung von Zugriffsrechten, wie oben 
beschrieben, in Kartenbetriebssystemen in der Regel nicht vorgesehen ist. 
Eventuell bedeutet dies besonderen Implementierungsaufwand. (Alternative: 
spezielles READ Kommando mit implizit festgelegtem Sicherheitsattribut). 

20 Datenfelder innerhalb der Records von Elementary Files werden nach folgenden 
Formaten unterschieden: ASCII, Binar, BCD, Datum, Formatstring. 

Datenelemente vom Typ „Formatstiing n enthalten VAS-Daten in gepackter 
Darstellung, die dem Karteninhaber am Terminal angezeigt werden kdnnen. 

25 

Zur optimalen Speicherausnutzung werden Klartext und binare Daten gemischt und 
(iber Formatiermakros darstellbar gemacht. 



Samtliche Elementary Files (EF) des VAS-Container sind nach ISO 7816-4 definiert 
30 als lineare formatierte EF Dateien mit Records konstanter Lange {linear fixed 
record files). 
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Das Elementary File EFJD des DF_VAS besteht aus einem Record, der die VAS- 
Container ID enthait. 



Das Elementary File EF_DIR des DF_VAS besteht aus nr DIR Records. Fur jede in 
5 den VAS-Container geladene VAS-Applikation wird in einem Record des EF_DIR 
ihr Proprietary Identifier Extension (PIX) und ihr physikalischer Speicherplatz (FID 
des DF_X, in den die Application geladen wurde) festgehalten. Die PIX identifiziert 
z.B. als Kennziffer die Applikation und den Service-Provider, dem die Applikation 
zugordnet ist. 

o 

Die Eintrage im EF_DIR werden am Service Terminal des System Operators 
dynamisch angelegt. Records ohne Eintrag werden mit einem leeren TLV Objekt 
•61' angelegt. 



15 Beim Laden einer VAS-Applikation wird zunachst ein freier Speicherbereich der filr 
sie passenden Implementierungsklasse gesucht, bestimmte VAS-Daten dort 
eingetragen und schlieftlich im EFJ3IR ein neuer Record erzeugt. 

Beim LOschen einer Applikation muli in EFJDIR entsprechend ein leeres TLV 
20 Objekt geschrieben werden. 

Das Elementary File EFJ/ERSION des DF_VAS besteht aus einem Record, der 
eine Versionsnummer des VAS-Container enthait. 

25 Die Versionsnummer kann von Terminals dazu benutzt werden, verschiedene 
VAS-Container-Varianten und/oder verschiedene Software-Versionen zu 
unterscheiden. 

Das Elementary File EF_SEQ des DF_VAS besteht aus einem Record, der die 
30 Nummer des nachsten Transferfeldeintrags enthait. 

Die Sequenznummer wird vom Erganzungskommando TRANSFER ausgelesen. 
Dieses Kommando erzeugt daraufhin im Transferfeld EFJTRANSFER einen 



WO 98/28718 



PCT/DE97/03012 



-Hi- 
Record, in den u.a. die Sequenznummer aus EF_SEQ ubertragen wird. Zusammen 

mit dem Kommando TAKE, das sicherstellt, dali jeder Record aus dem 

Transferfeld nur einmal entnommen wird und diese Entnahme per Signatur Qber 

die Sequenznummer dokumentiert, kann die einmalige Entnahme von (Original-) 

5 Gutscheinen bzw. Quittungen garantiert werden. 

Im folgenden soil nun genauer auf den Transferspeicher eingegangen werden. 

Der Transferspeicher wird innerhalb des VAS-Containers angelegt und umfaftt 
10 nr EF transfer Records. EintrSge in den Records dieses Files enthalten 
Transferdaten, die vom TRANSFER Kommando erzeugt werden. Ober den 
Transferspeicher wird sowohl der Datenaustausch zwischen VAS-Applikationen als 
auch die Speicherung von VAS-Daten der Klasse Gutschein abgewickelt. 

15 Der Transferspeicher kann ohne BeschrSnkung gelesen werden, der schreibende 
Zugriff ist jedoch nur durch die VAS-spezifischen Kommandos TRANSFER und 
TAKE moglich. 

Die Belegung der Datenfelder durch den TRANSFER Befehl geschieht durch einen 
20 ..Last-recently-used" Algorithmus in der Karte. Der aiteste Record in der Datei kann 
durch Suchen des kleinsten Wertes in den ersten 2 Bytes des Records ermittelt 
werden. 

Datenfelder kfinnen mit dem Befehl „TAKE M im Transferspeicher als entnommen 
25 und/oder entfemt markiert werden. In jedem Fall erfolgt das LOschen von Daten im 
Transferspeicher durch Oberschreiben mit neuen Daten. 

Jeder Record im Transferspeicher enthait beispielsweise ein Verfallsdatum, die 
Terminal-ID, die PIX, die Sequenznummer und eventuell weitere Daten. 

30 

Jedes Elementary File EFJNFO innerhalb von Verzeichnissen DF_X (mit X = PT 1t 
.... PT P , AD t AD a ) besteht aus einem Record, der das Verfallsdatum sowie 
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allgemeine VAS-Daten einer VAS-Applikation enthait. Beispielsweise kann die Art 
eines Tickets (Einzel- oder Streifenfahrschein) Oder der Einsteigeort hier 
angegeben werden. EFJNFO mud jedoch zumindest einen Klartextnamen der 
Applikation enthalten, der fur die Operation Ansehen VAS-Applikationen auslesbar 
5 ist Sensible Daten mu(J der VAS-Provider durch geeignete externe 
VerschlQsselungsalgorithmen schQtzen. 

Dieses EF ist Iesbar, wenn eine externe Authentifizierung mit K so oder K RVASP 
erfolgt oder der Karteninhaber im Falle eines aktivierten PIN-Schutzes eine 
10 korrekte PIN eingibt. 

Jedes Elementary File EFJNTERNAL innerhalb von Verzeichnissen DF_X (mit X = 

PT, PT P , AD 1p .... AD a ) besteht aus einem Record, der interne VAS-Daten des 

VAS-Provider Ober seine geladene VAS-Applikation enthalten kann. Weder 
15 Karteninhaber noch ein anderer VAS-Provider kdnnen diese intemen Daten lesen. 

Jedes Elementary File EF_VALUE innerhalb von Verzeichnissen DF_X (mit X = 
PT 1t PT P , AD 1f AD a ) besteht aus einem Record, der ein ganzzahliges 
Wertfeld der VAS-Daten enthalten kann. Dieses EF ist Iesbar, wenn eine externe 
20 Authentifizierung mit K so oder K RVA sp erfolgt oder der Karteninhaber im Falle eines 
aktivierten PIN-Schutzes eine korrekte PIN bzw. ein korrektes Pafiwort eingibt. 

Die folgenden SchlQsselfelder werden vom VAS-Container oder von der VAS- 
Applikation benutzt. Im folgenden wird von einer reinen DES-VerschlQsselung 
25 ausgegangen. D.h. samtliche Schlussel des VAS-Containers sind DES-Schlussel 
und sind in 8 byte codiert (einschlie&lich Paritatsbits). 



Innerhalb des VAS-Containers und innerhalb der VAS-Applikationen konnen 
folgende Schlussel durch ihren KID (Key Identifier) referenziert werden: 
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KEY 


KID 


Kso 


'00' 1 


K Airr 


'01 ' 


K Slfi YASC 


•02* 


KGKoec 


'03' 



Tabelle 5 - SchlQssel VAS-Container 

Jeder SchlQssel ist mit einem Fehlbedienungszahler verknQpft. Dieser registriert 
fehlgeschlagene Authentifizierungsversuche mit diesem SchlQssel und blockiert 
eine weitere Nutzung, wenn ein Limit fQr diesen Zahler eingetragen und erreicht ist. 

Innerhalb der VAS-Applikation konnen folgende SchlQssel durch ihren KID 
referenziert werden. 



KEY 


KID 




'04' 


K RYASR...... 


'05' 



Tabelle 6 • SchlUssel VAS-Applikation 

Jeder SchlQssel ist mit einem Fehlbedienungszahler verknQpft. Dieser registriert 
fehlgeschlagene Authentifizierungsversuche mit diesem SchlQssel und blockiert 
eine weitere Nutzung, wenn ein Limit fQr diesen Zahler eingetragen und erreicht ist. 

Der VAS-Container enthalt eine persdnliche Identifikationsnummer Oder Paliwort 
(PIN). Dies wird vom VERIFY Kommando zur Identifikation des Karteninhabers 
benutzt. Die PIN ist verknQpft mit einem Fehlbedienungszahler, der jede 
Falscheingabe registriert und bei Erreichen eines Limits den PIN-Vergleich spent. 
Diese Sperre kann durch den System Operator mit geeigneten Administrations- 
kommandos zurQckgesetzt werden. Der Fehlbedienungszahler wird bei korrekt 
eingegebener PIN zurQckgesetzt. 
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Es gibt folgende Parameter fur den VAS-Container, die vom Kartenherausgeber 
gemali dem zur VerfGgung stehenden Plate auf einer Kartenplattform und seinen 
individuellen Wunschen gewahlt werden konnen: 

• p Maximale Zahl von Objekten der Implementierungsklasse DF_PT 

= maximale Zahl von VAS-Applikationen der Applikationsklassen 
Punktespeicher und Ticket, die gleichzeitig in einen VAS-Container geladen 
werden kdnnen; 

• a Maximale Zahl von Objekten der Implementierungsklasse DF_AD 

= maximale Zahl von VAS-Applikationen der Applikationsklassen Ausweis und 
Datenspeicher, die gleichzeitig in einen VAS-Container geladen werden kdnnen; 

• nr D1R Maximale Gesamteahl von Objekten: nr DIR = p + a 
Die Anzahl von Records in EF_DIR ist nr DIR 

• n r EF_TRANSFER Anzahl von Records des EF_TRANSFER 

Der Speicherbedarf fdr die Gr5(ien der beschriebenen Elementary Files ist: 



Globale Daten des VAS-Containers: EF ID 



Byte 
4 



EF DIR 



EF VERSION 



9*(p+a) 
1 



EF SEQ 



2 



Globale Keys, Pin 
EF TRANSFER 



64+2 



Transferfeld: 



Proprietare Daten derVAS-Provider: EF_KEY 

EF INFO 



EF VALUE 



EF INTERNAL 



48 * nr EF TRANSFER 
(p+a) * 32 
(p+a) * 62 
p*10 
P*3 
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Wahlen wir z.B. fur die Parameter p, a und nr EF ^transfer folgende Werte, dann 

ergibt sich folgender Mindestspeicherbedarf fur den VAS-Container (ohne 
Speicherbedarf fur Erganzungskommandos): 

Parameter Speicherbedarf 

p = 8, a = 3, nr EF transfer = 1 5 2030 Byte 

p = 1 0, a = 5, nr EF transfer = 20 2758 Byte 



Der Maximalspeicherbedarf ist wahrscheinlich urn ca. 10% h6her als der 
10 Mi ndestspeicherbedarf . 

Im folgenden wird nun genauer auf die Kommandos der erfindungsgemSlien 
Chipkarte eingegangen. 

15 Das READ RECORD Kommando wird zum Ausiesen von Daten aus linearen 
Elementary Files benutzt. Die Karte liefert in der RQckantwort den Inhalt des 
Records. Das EF wird durch den Short File Identifier (SFI) referenziert. 

Der Status Code '9000' signalisiert eine erfolgreiche DurchfQhrung des 
20 Kommandos; jeder andere Code wird als Fehler bewertet. 

Der UPDATE RECORD Befehl wird benutzt, urn Daten in die Records eines 
linearen EF einzubringen. Die Kommandonachricht enthait die Referenz auf das 
EF, den Record und die Daten. 

25 

Die Antwort der Karte enthait den Statuscode. Der Statuscode '9000' signalisiert 
den erfolgreichen AbschluB der Kommandos. Andere Statuscodes zeigen den 
Fehlerfall an. 



30 Das GET CHALLENGE Kommando fordert von der Karte eine Zufallszahl an. Die 
Zufallszahl wird im Zusammenhang mit der dynamischen Authentifizierung im 
EXTERNAL AUTHENTICATE verwendet. 
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Die Antwortnachricht der Karte enthait eine 8 bytes lange Zufallszahl und den 
Statuscode. Der Statuscode '9000' zeigt die erfolgreiche AusfOhrung des 
Kommandos an. Andere Statuscodes zeigen den Fehlerfall an. 



Das Kommando EXTERNAL AUTHENTICATE erlaubt die Authentifizierung eines 
Terminals gegenQber der Karte. EXTERNAL AUTHENTICATE wird im Rahmen 
von VAS-Applikationen zur Authentifizierung des System Operators und des VAS- 
Providers benutzt. EXTERNAL AUTHENTICATE QbertrSgt ein Kryptogramm in die 

10 Karte, das zuvor vom Terminal durch Verschlusseln einer Zufallszahl erzeugt 
werden muB. Die Karte vergleicht das Kryptogramm mit einem Referenzwert, den 
sie selbst nach dem gleichen Verfahren berechnet hat. Sind beide Werte gleich, so 
vermerkt die Karte intern, dali die Zugriffsbedingung Authentifizierung fQr diesen 
Schlussel erfolgt ist. Sollte der Vergleich negativ ausfallen, so gibt die Karte den 

15 Status „Nicht autorisiert" zuruck und dekrementiert einen internen 
FehlbedienungszShler. Erreicht dieser ZShler den Wert 0, so wird jede weitere 
AusfOhrung des EXTERNAL AUTHENTICATE mit dem Status ^Authentifizierung 
gesperrt" abgewiesen. 

20 Die Antwortnachricht der Karte enthalt den Statuscode. Die erfolgreiche 
DurchfOhrung des Kommandos und die Authentifizierung der Terminals gegenuber 
der Karte wird durch den Statuscode '9000' angezeigt. Andere Statuscodes zeigen 
den Fehlerfall an. 

25 Das Kommando INTERNAL AUTHENTICATE wird benutzt, urn die Echtheit des 
VAS-Containers durch ein Terminal priifen zu konnen. Die Karte berechnet dazu 
ein Kryptogramm uber Referenzdaten vom Terminal. Das Terminal bildet 
seinerseits das Kryptogramm und vergleicht es mit dem Wert von der Karte. Bei 
Gleichheit kann das Terminal die Echtheit des VAS-Containers annehmen. 



5 



30 



Die Antwort der Karte enthalt das Kryptogramm und den Statuscode fur die Aus- 
fuhrung des Kommandos. Die erfolgreiche Durchfuhrung des Kommandos wird 




# 
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durch den Statuscode '9000* angezeugt. Andere Statuscodes zeigen den Fehlerfall 



Das VERIFY Kommando wird zur Verifikation der Karteninhaber PIN benutzt. Das 
5 Kommando Obertragt die PIN Daten unverschlusselt an die Karte, wo ein Vergleich 
mit einem gespeicherten Referenzwert durchgefuhrt wird. Sind eingegebener und 
gespeicherter Wert identisch, so wird die Zugriffsbedingung ..PIN" als erfiillt 
betrachtet. 

10 Die Antwortnachricht der Karte enthalt den Statuscode. Der Statuscode '9000' zeigt 
die erfolgreiche Durchfuhrung des Kommandos an. Andere Statuscodes zeigen 
den Fehlerfall an. 

Das TRANSFER Kommando erzeugt einen Eintrag im Transferspeicher. Drei 
15 Arbeitsmodi sind fur das Kommando definiert: 

1. Erzeugen eines Eintrags im Transferfeld durch Verringem von Werten im 
EF_VALUE Feld der Applikation der Klasse Ticket oder Punktespeicher. 

2. Erzeugen eines Eintrags im Transferfeld durch Erstellen einer Quittung in 
20 Applikationen der Klasse Ausweis. 

3. Erzeugen eines Eintrags im Transferfeld durch Erstellen eines Gutscheins in 
Applikationen der Klasse Gutschein. 

Der Arbeitsmodus wird durch die Karte automatisch ausgewahlt: Wird der Befehl 
25 innerhalb eines selektierten Applikations-DF ausgeftihrt, so wird zunachst das 
Vorhandensein eines EF_VALUE uberprtift. Bei vorhandenem EF_VALUE fuhrt die 
Karte den Befehl im Modus 1, ansonsten im Modus 2 durch. 1st innerhalb des VAS- 
Containers kein Applikations-DF ausgewahlt, wird Modus 3 benutzt. 



an. 



30 Das Terminal versorgt die Karte beim Aufruf des TRANSFER Kommandos mit den 
folgenden Daten: 
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• Aktuelles Datum 

• Verfallsdatum fur den Eintrag im Transferfeld 

• Identifikation fur das Terminal, welches diesen Eintrag erzeugt 

• Nutzdaten fur das Transferfeld 

5 • PIX der VAS-Applikation (nur Modus 3) 

• Anzahl abzuziehender Einheiten (nur Modus 1) 

• MAC Uber die o.g. Daten, die Sequenznummer und die VAS-Container Nummer. 

10 Die Karte fiihrt beim Aufruf des TRANSFER Kommandos die folgende Sequenz 
aus: 

1. Suchen nach einem freien Eintrag im Transferspeicher. (Die folgende 
Aufeahlung gibt absteigend die Prioritat wieder, in welcher vorhandene 
Eintragungen tiberschrieben werden sollen: „Eintrag als entfernt markiert", 

15 „Eintrag als entnommen markiert" und B Verfallsdatum erreicht\ „VerfaIlsdatum 
erreicht"). 

2. Anhangen der PIX an die Daten vom Terminal in den Modi 1 und 2. 

3. Anhangen der Sequenznummer an die Daten aus Schritt 2. 

4. Anhangen der VAS-Container ID an die Daten aus Schritt 3. 

20 5. Ableiten des KGK DEC PIX durch VerschlQsseln der PIX unter dem KGK DEC . 

6. Ableiten des K DEC durch VerschlQsseln der Terminal ID unter dem KGKq EC PIX . 

7. Erzeugung des MAC Qber die Daten aus Schritt 4. 

8. Vergleich des MAC aus Schritt 7 mit dem MAC vom Terminal. Sind die Werte 
unterschiedlich, bricht die Karte die Funktion ab und verringert den 

25 Fehlbedienungszahler fdr den KGKq EC . 

9. FGr Modus 1: Prtifung des Wertfeldes EF^VALUE im Verzeichnis, in das die 
Applikation geladen wurde. Sind nicht genugend Einheiten in diesem Feld 
vorhanden, bricht die Karte die Funktion an dieser Stelle ab. Andemfalls wird 
das Wertfeld in der Applikation urn den Betrag vermindert. 

30 10. Zusammenstellen der Kommandonachricht. 
11. Inkrementieren des Inhalts von EF_SEQ urn 1. 
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Die Ausgabe des Datensatzes in der Antwort ist daher nicht notwendig. Es kann 
weiterhin angenommen werden, daB die Nummer des Records bekannt ist. 

Das Kommando TAKE stellt folgende Modi bereit: 
5 • Entnahme mit gleichzeitigem Vermerk, daft die Daten ungQItig geworden sind 
• Entnahme ohne vorstehenden Vermerk. Die Daten bleiben weiterhin gQltig. 

Die Kommandonachricht enthait Felder mit Terminal-ID, PIX der Applikation und 
eine vom Terminal generierte Zufallszahl. 

10 

Die PIX im Kommando bezeichnet die entnehmende Anwendung. Sie darf 
verschieden sein von der PIX des Datensatzes, der entnommen wird. Sie dient 
ausschlielilich zur Ableitung von K DEC des entnehmenden Handlerterminals. 

15 Die Antwortnachricht der Karte enthait ein Kryptogramm C A mit K SIG V asc uber die 
Daten des in der Kommandonachricht angegebenen Records des Transferfeldes 
und die VAS-Container ID, ein Kryptogramm C 2 mit K DEC des entnehmenden 
Terminals Qber und die Zufallszahl aus der Kommandonachricht. Die 
Antwortnachricht enthait zusatzlich den Statuscode. Der Schlussel K DEC wird wie 

20 vorher beschrieben abgeleitet. Mit dem Kryptogramm vermSge K DEC wird implizit 
ein Echtheitsnachweis durch den VAS-Container erbracht. Mit dem Kryptogramm C 
wird ein Echtheitsnachweis und Einmaligkeitsnachweis (da C Qber Sequenz- 
nummer, Entnommen-Bit des Transferfeld-Records und VAS-Container ID gebildet 
werden) berechnet, den der Systemoperator verifizieren kann. 

25 

Der Statuscode '9000' zeigt die erfolgreiche DurchfOhrung des Kommandos an. 
Andere Statuscodes werden als Fehler interpretiert. 

Es ist davon auszugehen, daB der SO eine AID VA s gem§& ISO/IEC 7816-5 
30 beantragt. Genauer: Er beantragt eine 5 Byte lange RID VAS filr das VAS-System. 

Die AIDvas des Verzeichnisses DF_VAS soil lauten: AID VAS = RIDvas-P'Xdf vas- 
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Die Kommandonachricht enthait beispielsweise Felder mit einem Verfallsdatum, 
der Terminal ID, den Transaktionsdaten, ein Feld fur den Betriebsmodus (enthait 
z.B. im Modus 3 die PIX), sowie ein Kryptogramm. 

Das Kryptogramm wird unter Verwendung des Schlussels K 0EC berechnet, wobei 
die Daten, Qber die der MAC gebildet wird, beispielsweise die Transaktionsdaten 
und die Terminal-ID umfassen. 

Die Antwortnachricht des TRANSFER Kommandos umfalit im Erfolgsfall einen 8 
Byte langes Datenfeld und den 2 Byte langen Statuscode '9000*. 
Antwortnachrichten mit einem von '9000' verschiedenen Statuscode werden als 
Fehlercode interpretiert. Das Datenfeld der Antwortnachricht enthait im fehlerfreien 
Fall (d.h. insbesondere war das Kryptogramm der Kommandonachricht korrekt) das 
mit K 0EC verschltisselte Kryptogramm der Kommandonachricht. Dadurch wird 
implizit (anstelle einer intemen Authentifizierung mit K AUT ) ein Echtheitsnachweis 
durch den VAS-Container erbracht. 

Das Kommando TAKE dient zur Entnahme von Objekten aus der 
Implementierungsklasse EF_TRANSFER. Technisch bedeutet die Ausfuhrung des 
Kommandos TAKE das Auslesen eines anzugebenden Records aus der Datei 
EF_TRANSFER, wobei der Record in der Datei so lange verbleibt, bis der 
Speicherplatz fur neue Eintrage benOtigt wird, der Datensatz wird als entnommen 
markiert. Technisch gesehen kann jeder das Kommando TAKE nutzen, urn einen 
Datensatz zu entnehmen, nach den R&R sollte dies jedoch nur ein VAS-Provider 
tun, fur den der Datensatz bestimmt ist. 

FQr den Entnahmevorgang kann folgendes angenommen werden. Der VAS- 
Provider, der einen Gutschein oder eine Quittung entnehmen will, durchsucht den 
Transferspeicher nach einem passenden Datensatz (z.B. durch das Kommando 
SEEK oder durch explizites Lesen jedes Records). Der Datensatz wird in jedem 
Fall gelesen und eventuell inhaltlich gepriift. 
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Fur jede VAS-Applikation A wird gemali R&R eine 3 Bytes lange PIX A vergeben, 
urn sie innerhalb des VAS-Container eindeutig mit AID A = RID VAS .PIX A Identifizieren 
zu kdnnen. Nach der Selektion des DF_VAS kann ein Verzeichnis, in dem die 
VAS-Applikation A enthalten ist, mit SELECT FILE < PIX A > ausgewahlt werden. 

Mit dem UPDATE KEY(KID, K) sei ein von der Kartenplattform abhangiges 
Kommando bezeichnet, mit welchem ein SchlQssel mit Key Identifier ID durch den 
neuen Wert K ersetzt wird. 

Bevor eine VAS-Applikation aus einer der Implementierungsklassen DF_PT Oder 
DF_AD (dies entspricht den Applikationsklassen Punktespeicher, Ticket, Ausweis 
oder Datenspeicher) durch den Karteninhaber an Handlerterminals genutzt werden 
kann, muli sie an einem Serviceterminal des zustandigen VAS-Provider in den 
VAS-Container geladen werden. Prinzipiell ist auch mfiglich, daft ein 
Kartenherausgeber im Auftrag eines VAS-Provider und eines SO bereits beim 
Aufbringen des VAS-Containers eine oder mehrere VAS-Applikationen in den VAS- 
Container ladt. Dieser Ladevorgang ist ein Spezialfall des hier beschriebenen. 

Ablaut des Ladens einer VAS-Applikation: 

1 . Karteninhaber fuhrt eine VAS-Karte in ein Serviceterminal ein. 

2. Das Serviceterminal prtlft, ob ein VAS-Container vorhanden ist: 

• SELECT FILE < AIDv AS > (Fehlermeldung wenn VAS-Container nicht 
selektierbar) 

• READ RECORD < SFI von EFJD, 0 > (Auslesen der VAS-Container 
Nummer) 

Optional wird die Gultigkeit des VAS-Containers gepriift. Dazu veriangt das 
Serviceterminal eine interne Authentrfiziening des VAS-Containers: 
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10 

4. 

15 
20 

5. 

25 



• INTERNAL AUTHENTICATE < Zufallszahl, KID von K AUT > 
Das Serviceterminal prOft die Antwort und bricht im Fehlerfall (mit 
Fehlermeldung) ab. 

Das Serviceterminal stellt dem Karteninhaber mehrere Optionen zur Auswahl. 
Eine davon lautet Laden VAS-Applikation. Diese wahlt der Karteninhaber aus. 
Nun werden dem Karteninhaber alle VAS-Applikationen, die am 
Serviceterminal geladen werden kdnnen, angezeigt, und es wird auf eine 
Auswahl gewartet. Dazu wird die Operation Ansehen VAS-Applikationen 
aktiviert. Der Karteninhaber wahlt eine VAS-Applikation A der 
Implementierungsklasse DF_PT oder DF_AD aus. 

Das Serviceterminal untersucht den VAS-Container mit der Operation Selektion 
einer VAS-Applikation, ob die ausgewShlte VAS-Applikation mit PIX A bereits in 
der Karte geladen ist. Falls ja, wird eine Fehlermeldung ausgegeben. Falls 
nicht, wird geprilft, ob noch ein Objekt der fur A geeigneten 
Implementierungsklasse im VAS-Container frei ist. Dies geschieht durch 
Suchen eines freien Records in EFJ3IR (z.B. mit dem Kommando SEEK). 
Falls nichts frei ist, wird eine Fehlermeldung ausgegeben. Falls ein Record frei 
ist, enthait dieser eine FID DF x eines DF_X f in das keine VAS-Applikation 
geladen ist. 

Das nachste freie Objekt der fOr A geeigneten Implementierungsklasse wird 
belegt fur die VAS-Applikation A. Dabei erfragt zunSchst das Serviceterminal 
offline vom VAS-Provider (z.B. durch ein VAS-Provider-SAM) zwei SchlQssel 
k lvasp und k rvasp und weist sie der neuen VAS-Applikation zu: 



• SELECT FILE < FID, 



'DF X 



> 



• GET CHALLENGE 



• EXTERNAL AUTHENTICATE < K s0 (Zufallszahl) f KID von K s0 > 

# UPDATE KEY < KID von K LVASPf K LVASP > 
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• UPDA TE KEY < KID von K RVASP , K RVASP > 

• GET CHALLENGE 

• EXTERNAL AUTHENTICATE < K LVASP (Zufallszahl), KID von K LVASP > 

• UPDATE RECORD < SFI von EFJNFO des DF_X, Daten > 

5 • UPDATE RECORD < SFI von EFJNTERNAL des DF_X, Daten > 

• Optional (Initialisierung): UPDATE RECORD < SFI von EF_VALUE des 
DF_X, Daten > 

6. Nach dem erfolgreichen Schreiben in die EFs wird vom Serviceterminal die 
10 Operation Eintrag VAS-Applikation < P/X^ FID D ^ X > ausgefuhrt, die das DF_X 
mit dem PIX A verbindet und so SELECT FILE mittels des PIX A (nach der 
vorherigen Selektion mit SELECT FILE AID VA s) ermdglicht. 

Der mit dem Transferspeicher zur Verfugung gestellte Mechanismus laiJt sich z.B. 

15 von VAS-Providern nutzen, die Intra- oder Interservices ohne proprietare DF- 
Strukturen abwickeln mochten. Ein Karteninhaber mu(i dann insbesondere vor der 
Benutzung einer VAS-Applikation diese nicht erst an einem Serviceterminal laden. 
Er kann dagegen direkt am Handlerterminal sich einen Gutschein oder eine 
Quittung ausstellen und diese an einem anderen Terminal erstatten (durch die 

20 Operation Entnehmen) lassen oder den Gutschein bzw. die Quittung nur einfach 
vorweisen (durch Lesen). Das Laden einer VAS-Applikation der 
Implementierungsklasse EF_TRANSFER wird daher implizit durch Aufbringen von 
VAS-Daten realisiert bzw. auf diese Operation zuruckgefuhrt. Hierzu wird auf die 
spater folgende Beschreibung des Erwerbens der Implementierungsklasse 

25 EF_TRANSFER verwiesen. 

Nachfolgend wird der Ablaut der Operation des Eintrags einer VAS-Applikation 
beschrieben. 

30 1st eine VAS-Applikation in den VAS-Container geladen, ist einem Terminal der 
physikalische Ort unbekannt, in welchem DF_X mit X = PT 1t PT P , AD 1f .... AD a 
die VAS-Applikation bzw. ob sie Oberhaupt geladen ist. Aus Sicht des 
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Kartenherstellers sind zwei m6gliche Implementierungsweisen mdglich, die 
getrennt gepriift werden sollen; dabei ist insbesondere die Konsistenz zum ZKA- 
Standard zu beachten. 

5 Der erste Fall: Zugriff auf EFJDIR mdglich 

Folgende Voraussetzungen sind zu erfiillen: 

• Es gebe standardmS&ig in der Kartenplattform ein EFJ3IR (z.B. unter DF_VAS), 
10 in dem AIDs den FIDs der DF_X zugeordnet sind, in denen sich VAS- 

Applikationen aktuell befinden. 

• Dieses EFJDIR ist fOr jeden lesbar (AC von READ RECORD: ALW). 

• Wird eine VAS-Applikation A mit PIX A vom System Operator in ein freies 
(unbenutztes) DF_X geladen, d.h. die vorhandenen Elementary Files dieses 

15 DF_X beschrieben (kein CREATE FILE !), dann soil durch ein UPDATE 
RECORD die Datei EF_DIR urn den Eintrag PIX A erweitert werden kfinnen, der 
auf dieses DF_X verweist mit FID X . Die AC von UPDATE RECORD sollte daher 
eine externe Authentisierung mit dem SchlQssel K so erzwingen. 

• Wird der Befehl SELECT FILE < PIX A > nach der vorherigen Selektion von 
20 DF_VAS an die Karte Gbermittelt, muft das DF_X f in das eine VAS-Applikation A 

geladen ist, direkt selektierbar sein. 

• Wenn eine VAS-Applikation A, die in DF_X und den darunterliegenden 
Elementary Files geladen ist, auf Wunsch des Karteninhabers an einem Service- 
Terminal gelflscht werden soli, werden die entsprechenden Dateien nicht mit 

25 DELETE FILE gelOscht, sondern die eingetragenen Daten lediglich mit Dummy- 
Werten Qberschrieben. Danach soil aus EF_DIR der Eintrag PIX A (genauer das 
Paar PIX A und der Verweis auf DF_X) geldscht werden kSnnen (z.B. durch 
UPDATE RECORD mit vorheriger extemer Authentisierung mit dem SchlQssel 



K so ). 
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• Da die Anzahl der DF_X fest ist, ist die Anzahl der Records von EF_DIR 
bekannt. 

ist dieser Ansatz realisierbar. ergibt sich folgende Konsequenz: 

• Ein nach Selektion von DF_VAS direkt erfolgendes Selektieren einer VAS- 
Applikation mit SELECT FILE PIX A ist moglich. 

Derzweite Fall: Zugriff auf EF_DIR nicht moglich 

Stent bei der Kartenplattform kein EF_DIR zur VerfQgung oder ist kein lesender 
und schreibender Zugriff auf dieses EF_DIR - wie im obigen Abschnitt dargestellt - 
mOglich, soil es unter DF_VAS eine Datei EF_VASDIR geben, in der vom System 
Operator durch explizite UPDATE RECORD Befehle (nach vorheriger externer 
Authenfrfizierung mit K so ) ein Bezug der PIX A geladener VAS-Applikationen zu 
ihrem physikalischem Speicherplatz in einem DF_X hergestellt wird. Das Lesen 
und Laschen von Records aus EF_VASDIR soli wie vorher beschrieben moglich 
sein. 

Der Ablauf der Operation Eintrag VAS-Applikation lauft wie folgt: 

Eine VAS-Applikation A mit PIX A wurde vorher in ein freies DF_X mit FID DF x 
geladen. Die Nummer des Records mit FID DFX wurde vom Serviceterminal 
vermerkt. 

1. SELECT FILE < AIDv AS > (Fehlermeldung wenn VAS-Container nicht 
selektierbar) 

2. GET CHALLENGE 

3. EXTERNAL AUTHENTICATE < K S0 (Zufallszahl), KID von K so > 

4. UPDATE RECORD < SFI von EF_DIR des DF_VAS, Nummer Record mit 
FID 0F X , PIX Al FID DF X > 
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VAS-Applikationen der Implementierungsklassen DF_PT Oder DF_AD kdnnen nur 
an Serviceterminals (da unter Hoheit des System Operator) auf Wunsch des 
Karteninhabers gelflscht werden, VAS-Applikationen der Implementierungsklasse 
EF_TRANSFER kflnnen Qberall und von jedem gelbscht werden. Beim Loschen zu 
unterscheiden sind VAS-Applikationen der Implementierungsklassen DF_PT und 
DF_AD bzw. der Implementierungsklasse EFJTRANSFER. 

Ablauf des Lttschens einer solchen VAS-Applikation fQr die Implementierungs- 
klasse DF_PT Oder DF_AD: 

1 . Der Karteninhaber fCShrt eine VAS-Karte in ein Serviceterminal ein. 

2. Das Serviceterminal prtift, ob ein VAS-Container vorhanden ist: 

• SELECT FILE < AID VAS > (Fehlermeldung wenn VAS-Container nicht 
selektierbar) 

• READ RECORD < EFJD > (Auslesen der VAS-Container ID) 

3. Das Serviceterminal stellt dem Karteninhaber mehrere Optionen zur Auswahl. 
Eine davon lautet L&schen VAS-Applikation. Diese wahlt der Karteninhaber 
aus. Nun werden dem Karteninhaber alle VAS-Applikationen aller 
Implementierungsklassen, die im VAS-Container geladen sind, angezeigt, und 
es wird auf eine Auswahl gewartet. Dazu wird die Operation Ansehen W\S- 
Applikationen aktiviert. Der Karteninhaber wahlt eine VAS-Applikation A der 
Implementierungsklasse DF_PT oder DF_AD mit AID A aus. Das Objekt, in dem 
die VAS-Applikation geladen ist, heilie DF_A. 

4. Nach der Selektion des DF_A authentisiert sich das Serviceterminal: 

• SELECT FILE <PIX A > 

• GET CHALLENGE 

• EXTERNAL AUTHENTICATE < K S0 (Zufallszahl). KID von K s0 > 

5. Nun wird der Inhalt der Dateien aus DF_A geldscht (fOr EF_KEY, 
EFJNTERNAL und EF_VALUE sind der K LVASP notwendig, deshalb wird dieser 
zuerst vom System Operator gelOscht): 

• UPDA TE KEY < KID von K LVASPt "00. . .00" > 
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• UPDATE KEY < KID von K RVASP , "00... 00" > 

• GET CHALLENGE 

• EXTERNAL AUTHENTICATE < K LVAS p(Zufallszahi), KID von FWp > 

• UPDATE RECORD < SFI von EFJNFO des DF_A, "00... 00" > 

5 • UPDATE RECORD < SFI von EFJNTERNAL des DF_A, "00.. .00" > 

• UPDATE RECORD < SFI von EF_VALUE des DF_A, "00.. .00" > 

6. Nach einem erfolgreichen Schreiben in die EFs wird abschlieftend vom 
Serviceterminal der Eintrag der VAS-Applikation aus EF_DIR geloscht: 

• SELECT FILE < AIDvas > (Fehlermeldung wenn VAS-Container nicht 
10 selektierbar) 

• UPDATE RECORD < SFI von EF_DIR des DF_VAS, Nummer Record mit 
FID DF _ A , "00...00", FID DF A > 

Die Verbindung von PIX A zum DF_A wird dadurch aufgeldst, so dali SELECT FILE 
15 mit dem PIX A nicht mehr moglich ist. 

Nun fQr die Implementierungsklasse EF_TRANSFER: 

Eine VAS-Applikation der Implementierungsklasse EF_TRANSFER soil nach R&R 
20 nur auf expliziten Wunsch eines Karteninhabers an einem Handlerterminal oder 
Serviceterminal geloscht werden (auch wenn dies technisch durch beide mfiglich 
ware). Das LOschen eines Objektes aus EFJTRANSFER wird insbesondere dann 
notwendig, wenn der Transferspeicher keinen Platz mehr enthait fQr die 
Speicherung eines neuen Objektes (z.B. einen Gutschein oder eine Quittung). Das 
25 L6schen geschieht immer indirekt Ober das Erganzungskommando TAKE. Dieses 
Kommando markiert nur ein Objekt als entfernt. Damit ist es zum Oberschreiben 
durch ein nachfolgendes Erganzungskommando TRANSFER freigegeben. 

Ablauf des Lflschens dieser VAS-Applikation: 



30 
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1. Der Karteninhaber fiihrt eine VAS-Karte in ein Terminal ein, welches den Inhalt 
von EFJTRANSFER darstellen kann (Spezialfall von Operation Ansehen VAS- 
Applikationen). 

5 2. Das Terminal prtlft, ob ein VAS-Container vorhanden ist: 

• SELECT FILE < AID VAS > (Fehlermeldung wenn VAS-Container nicht 
selektierbar) 

• READ RECORD < SFI von EFJD, 0 > (Auslesen der VAS-Container ID) 

10 3. Das Terminal stellt dem Karteninhaber mehrere Optionen zur Auswahl. Eine 
davon lautet Loschen VAS-Applikation. Diese wShlt der Karteninhaber aus. Nun 
werden dem Karteninhaber zumindestens die VAS-Applikationen der 
Implementierungsklasse EFJTRANSFER angezeigt, und es wird auf eine 
Auswahl gewartet. Dies wird durch einen Spezialfall der Operation Ansehen 

15 VAS-Applikationen realisiert. Der Karteninhaber wahlt ein Objekt der 
Implementierungsklasse mit einem Gutschein bzw. einer Quittung aus. Dieses 
Objekt besitze die Recordnummer A. Der Karteninhaber bestatigt die Auswahl. 

4. Das Terminal markiert den Record mit Recordnummer A als entfernt, indem es 
20 A, eine von ihm berechnete Zufallszahl, seine PIX und Terminal ID mit dem 
Kommando TAKE Qbermittelt: 

• TAKE < A, Zufallszahl, PIX, Terminal ID > 

Nun steht der als entfernt markierte Record wieder zur Verfugung zur Aufnahme fur 
25 einen neuen Gutschein oder eine Quittung. 

Nachfolgend der Ablauf der Selektion einer VAS-Applikation: 

Ist eine VAS-Applikation A der Implementierungsklassen DF_PT oder DF_AD in 
30 den VAS-Container mit der Operation Laden VAS-Applikation geladen worden, 
kann sie zweistufig von einem Terminal selektiert werden. Zuerst wird der VAS- 
Container selektiert und danach die VAS-Applikation mit ihrer PIX A : 
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1 . SELECT FILE < AID VA s > (Fehlermeldung wenn VAS-Container nicht 
selektierbar) 

Ein Serviceterminal kann die Echtheit des VAS-Containers prOfen. Dazu veriangt 
5 ein Serviceterminal eine interne Authentifizierung des VAS-Containers: 

• READ RECORD < SFI von EFJD, 0 > (Auslesen der VAS-Container ID) 

• INTERNAL AUTHENTICATE < Zufallszahl, KID von K AUT > 

10 Das Serviceterminal pruft die Antwort und bricht im Fehlerfall (mit 
Fehlermeldung) ab. 

2. SELECT FILE < PIX A > (Fehlermeldung, falls VAS-Applikation A nicht in den 
VAS-Container geladen ist) 

15 

Ein Handlerterminal (welches nicht Qber den KGIW verfiigt) kann indirekt die 
Echtheit des VAS-Containers durch die EchtheitsprOfung der VAS-Applikation A 
feststellen. Denn eine VAS-Applikation kann nur an einem Serviceterminal geladen 
worden sein, die beim Ladevorgang die Echtheit des VAS-Containers geprilft hat. 
20 Die EchtheitsprOfung der VAS-Applikation A kann auf den Test des 
Handerterminals zurtlckgefOhrt werden, ob der VAS-Container den SchlQssel 
Klvasp oder den K RVA sp I0r die VAS-Applikation A enthalt. Dies kann das 
Handlerterminal z.B. kontrollieren durch: 

25 • INTERNAL AUTHENTICATE < Zufallszahl, KID von Krvasp oder K^p > 

Urn zu testen, ob eine VAS-Applikation A im VAS-Container geladen ist, kann sie 
probeweise selektiert werden; aufgrund der Fehlermeldung der Antwortnachricht 
von SELECT FILE kann daraus geschlossen werden, daft sie nicht vorhanden ist. 

30 
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Eine Selektion einer VAS-Applikation der Implementierungsklasse EF_TRANSFER 
ergibt sich implizit durch die Operation Ansehen VAS-Applikationen und das 
Speichern der Daten im Terminal. Da das Terminal die Recordnummer von jedem 
angezeigten Objekt aus EF_TRANSFER kennt, kann per Recordnummer ein 
5 beliebiges Objekt zur Weiterverarbeitung durch Bezugnahme auf die 
Recordnummer selektiert werden. 

Nachfolgend der Ablaut des Ansehens einer VAS-Applikation: 

10 Die Operation Ansehen von VAS-Applikationen listet an einem Serviceterminal 
sSmtliche VAS-Applikationen der Implementierungsklassen DF_PT, DF_AD und 
EF_TRANSFER auf. An einem Handlerterminal kdnnen nur die VAS-Applikationen 
der Implementierungsklasse EFJTRANSFER angezeigt werden, da fur diese kein 
Zugriffsschutz existiert, und optional Applikationen der Implementierungsklasse 

15 DF_PT bzw. DF_AD, fQr die das Handlerterminal Leserechte besitzt (Besitz von 
Krvasp)- 

Ablauf einer solchen VAS-Applikation: 

20 1 . Der Karteninhaber fOhrt eine VAS-Karte (Chipkarte mit gQltigem VAS-Container) 
in das Terminal ein. 

2. Das Serviceterminal prtift, ob ein VAS-Container vorhanden ist: 

25 • SELECT FILE < AID VAS > (Fehlermeldung wenn VAS-Container nicht 

selektierbar) 

• READ RECORD < SFI von EFJD, 0 > (Auslesen der VAS-Container ID) 



Optional wird die GQItigkeit des VAS-Containers gepriift. Dazu verlangt das 
30 Serviceterminal eine interne Authentifizierung des VAS-Containers: 
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• INTERNAL AUTHENTICATE < Zufallszahl, KID von K AUT > 

Das Serviceterminal prQft die Antwort und bricht im Fehlerfall (mit 
Fehlermeldung) ab. 

3. Das Serviceterminal stellt dem Karteninhaber mehrere Optionen zur Auswahl. 
Eine davon lautet Ansehen VAS-Applikationen. Diese wahlt der Karteninhaber 
aus. 

4. Das Serviceterminal authentisiert sich: 

• GET CHALLENGE 

• EXTERNAL AUTHENTICATE < K S0 (Zufallszahl) f KID von K s0 > 

5. Fur VAS-Applikationen der Implementierungsklassen DF_PT und DF_AD 
werden Ober den Inhalt von EFJDIR gesteuert nacheinander die einzelnen VAS- 
Applikationen selektiert und nach einer externen Authentifizienjng mit dem 
SchlOssel K s0 der Inhalt der einzelnen EFJNFO (oder ein Teil davon nach R&R) 
sowie EF_VALUE angezeigt: 

• FQr i = 0, .... nr DIR - 1 

• READ RECORD < SFI von EF_DIR, i > 

In der Antwortnachricht steht PIX Af die n 00..00" ist, wenn in das 
entsprechende DF keine VAS-Applikation geladen ist. Altemativ zum 
READ RECORD aus EF_DIR kann eventuell auch ein SEEK 
Kommando benutzt werden. 

• WennPIX A ungleich*00..00 M 

• SELECT FILE <PIX A > 

• READ RECORD < SFI von EFJNFO, 0 > 

• Anzeigen (eventuell eines Teils) der Antwortnachricht 

• READ RECORD < SFI von EF_VALUE, 0 > 

• SELECT FILE <AID VAS > 
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6. Fur VAS-Applikationen der Implementierungsklasse EFJTRANSFER wird der 
Inhalt (oder ein Teil davon nach R&R) des EFJTRANSFER eines jeden Records 
gelesen: 

5 

• SELECT FILE <AID VAS > 

• Fur i = 0, ...,nr EF transfer -1 

• READ RECORD < SFI von EFJTRANSFER, i > 

(in der Antwortnachricht steht Inhalt des i-ten Records von 
10 EFJTRANSFER) 

• Wenn Inhalt nicht leer ist, wird der Inhalt interpretiert (z.B. 
entnommen/verfallen) angezeigt. 

Das Ansehen der Applikationen der Implementierungsklasse DF_PT bzw. DF_AD, 
15 fQr die das Handlerterminal Leserechte besitzt (Besitz von K RVA sp). ertblgt wie 

beschrieben - mit zwei Abweichungen: Zur externen Authentifizierung wird anstelle 

des K so , Ober den nur der System Operator verfugt, der Schlussel K RVA sp benutzt. 

VerfQgt ein Handlerterminal nicht Ober den KGK AUT und mochte dennoch die 

Echtheit der VAS-Applikationen prQfen, kann das Handlerterminal anstelle der 
20 internen Authentifizierung die Authentifizierung (zumindest einer) VAS-Applikation 

verlangen. Dies geschieht, wie aufgefQhrt, durch Kenntnis der Karte des 

entsprechenden K RV asp oder k lvasp Schlussels. 

Fur VAS-Applikationen der Implementierungsklasse EFJTRANSFER wird der Inhalt 
25 (oder ein Teil davon nach R&R) des EF_TRANSFER jedes Records nacheinander 
aufgelistet, wie vorher beschrieben. 

Die Operation Interpretieren VAS-Applikationen veriauft dazu analog. Das Terminal 
stellt dazu dem Karteninhaber eine Option Interpretieren VAS-Applikationen zur 
30 Auswahl. Zusatzlich zu den Daten, die durch die Operation Ansehen sichtbar 
werden, kflnnen auch Daten aus EFJNFO und EF_VALUE, die einer Interpretation 
durch den VAS-Provider bedQrfen (z.B. extern verschlQsselte Daten) und Daten 
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aus EFJNTERNAL (z.B. Meilen der vergangenen Jahre bei Miles & More), 
dargestellt werden. Dies ist jedoch nur fQr die VAS-Applikationen moglich, for die 
ein VAS-Provider (nach seinen eigenen Vorstellungen) am Terminal geeignete 
SchlQssel zur Verfugung stellt. Zum Lesen des EFJNTERNAL einer VAS- 
5 Applikation ist der SchlQssel K LVASP (externe Authentifizierung) notwendig. FQr 
extern verschlusselte Daten innerhalb der Elementary Files EFJNFO, EFJNTERN 
und EF_VALUE sowie des Transferspeichers EF_TRANSFER werden die 
entsprechenden SchlQssel des VAS-Providers bendtigt. Das Terminalprogramm 
kann anhand der PIX einer selektierten VAS-Applikation leicht entscheiden, fQr 
10 welche Applikationen Schlussel fOr die Interpretation der Daten zur VerfQgung 
stehen. 

Die Operation Obertragen von VAS-Applikationen bedeutet das Obertragen aller 
oder ausgewahlter VAS-Operationen einer Quell-Karte auf eine Ziel-Karte an 

15 einem Serviceterminal. Bedingung ist hierbei, dali im VAS-Container der Zielkarte 
keine VAS-Applikationen geladen sind und nach der Obertragung auf der Quell- 
Karte alle VAS-Applikationen geloscht werden. Beides kann durch sukzessive 
Anwendung der Operation Loschen einer VAS-Applikation erreicht werden. 
AulJerdem muli die Echtheit der VAS-Karten geprtlft werden und die Ziel-Karte 

20 Qber ausreichend Speicherplatz verfQgen. Die Operation Obertragung selbst 
basiert im wesentlichen auf einer Erweiterung der Operation Ansehen von VAS- 
Applikationen, bei der zusatzlich die Daten aus EFJNTERNAL und die SchlQssel 
k lvasp und K R vasp gelesen werden, und einer wiederholten Anwendung der 
Operation Laden einer VAS-Applikation. 

25 

Mit den VAS-Daten wird auch die VAS-Container ID mit auf die Ziel-Karte 
Obertragen, damit sich VAS-Applikationen auf der Ziel-Karte genau so verhalten 
wie auf der Quell-Karte. Der Grund hierfOr ist, dali von einem VAS-Provider 
abgeleitete SchlQssel sich auf die VAS-Container ID stOtzen, die SchlQssel aber 
30 unverandert kopiert werden. AulSerdem machte ein VAS-Provider seine 
BuchfOhrung im Hintergrundsystem nicht andern, da er VAS-Karten ublicherweise 
Qber die VAS-Container ID identifiziert. Unbedingt zu beachten ist bei der 
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Obertragung der VAS-Container ID, daft diese systemweit eindeutige Nummer auf 
der Quell-Karte geldscht wird. 

Um speziell das Elementary File EFJNTERNAL und die SchlQssel K LVASP und 
s K R vasp lesen zu kdnnen, Gberschreibt das Servicetenminal nach einer externen 
Authentifizierung mit dem SchlQssel K so (analog wie bei der Operation Ldschen 
einer VAS-Applikation) zuerst die SchlQssel K LVA sp und kann dann nach einer 
erneuten Authentifizierung mit K LVA sp die Daten aus EFJNTERNAL Qbertragen. 

10 ZusStzlich zu den VAS-Applikationen der Implementierungsklassen DF_PT und 
DF_AD muft die Datei EFJTRANSFER Qbertragen werden. Dazu werden mit der 
Operation Entnehmen nacheinander die Objekte dieser Implementierungsklasse 
entfernt, die nicht bereits als entfernt Oder verfallen markiert sind, ihre Signatur mit 
k sig_vasc gepruft und in das EFJTRANSFER der Ziel-Karte Qbertragen. Auf der 

15 Ziel-Karte werden allerdings die Objekte als nicht entnommen gekennzeichnet, 
damit sie weiterhin gQltig bleiben. 

SchlieRlich mQssen noch die globalen Daten des VAS-Containers Qbertragen 
werden. Insbesondere muli der SequenzzShler der Ziel-Karte auf den Wert der 
20 Quell-Karte eingestellt werden. 

Nachfolgend das Verfahren des Aufbringens von VAS-Daten: 

Es gibt drei mfigliche FSIIe fOr das Aufbringen von VAS-Daten an einem 
25 Handlerterminal, die von der Art der VAS-Applikation abhangen. 

Zunalchst das Erwerben im Falle der Implementierungsklasse DF_PT oder DF_AD 

Es sollen von einem VAS-Provider Daten in eine VAS-Applikation A der 
30 Implementierungsklasse DF_PT oder DF_AD geschrieben werden. 
Ablauf des Aufbringens von VAS-Daten: 

1 . Der Karteninhaber fQhrt eine VAS-Karte in ein Handlerterminal ein. 
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2. Das Handlerterminal priift, ob ein VAS-Container vorhanden ist: 

• SELECT FILE < AID VA s > (Fehlermeldung wenn VAS-Container nicht 
5 selektierbar) 

• READ RECORD < SFI von EFJD, 0 > (Auslesen der VAS-Container ID) 

3. Es wird die Echtheit des VAS-Containers geprQft. 

10 Ist das Handlerterminal selbst in Besitz des Masterkeys KGK AirTl kann es eine 
interne Authentifizierung des VAS-Containers verlangen: 

• INTERNAL AUTHENTICATE < Zufallszahl, KID von K AUT > 

15 Ein Handlerterminal (welches nicht Qber den KGK AUT verfilgt) kann indirekt die 
Echtheit des VAS-Containers durch die Echtheitsprilfung der VAS-Applikation A 
feststellen. Denn eine VAS-Applikation kann nur an einem Serviceterminal 
geladen worden sein, die beim Ladevorgang die Echtheit des VAS-Containers 
gepriift hat. Die EchtheitsprQfung der VAS-Applikation A kann auf den Test des 

20 Handlerterminals zurtickgefuhrt werden, ob der VAS-Container den Schlussel 
k lvasp oder den K RVA sp *Dr die VAS-Applikation A enthait. Dies kann das 
Handlerterminal z.B. kontrollieren durch: 

• SELECT FILE < PIX A > (Fehlermeldung, falls VAS-Applikation A nicht in 
25 den VAS-Container geladen ist) 

• INTERNAL AUTHENTICATE <Zufallszahl, KID von Krvasp oder K LVASP > 

Das Handlerterminal prOft die Antwort und bricht im Fehlerfall (mit 
Fehlermeldung) ab. 

30 



WO 98/28718 



PCT/DE97/03012 



- 6^ 

4. Das Handlerterminal selektiert die VAS-Applikation A, authentisiert sich und 
beschreibt die Elementary Files, die fur die Abwicklung der Transaktion 
notwendig sind: 



5 • SELECT FILE < PIX A > (entfailt, wenn bereits in Schritt 3 durchgefQhrt) 

• GET CHALLENGE 

• EXTERNAL AUTHENTICATE < K LV Asp(Zufallszahl), KID von K LVASP > 

• optional: UPDATE RECORD < SFI von EFJNFO des DF_X, Daten > 

• optional: UPDATE RECORD < SFI von EFJNTERNAL des DF_X, Daten > 
10 • optional: UPDATE RECORD < SFI von EF_VALUE des DF_X, Daten > 

Als nSchstes das Erwerben im Falle der Implementierungsklasse EF_TRANSFER 



Speziell fur VAS-Applikationen der Implementierungsklasse EF_TRANSFER 
15 (Applikationsklasse Gutschein) muR ein VAS-Provider keine proprietare 
Dateistruktur DF_X fur seine Applikation belegen. Die Folge ist, dali ein 
Karteninhaber nicht vor der Nutzung einer VAS-Applikation Gutschein an ein 
Serviceterminal gehen mull, urn eine VAS-Applikation zu laden. Er kann dagegen 
direkt am Handlerterminal sich einen Gutschein Oder eine Quittung ausstellen und 
20 diese an einem anderen Terminal erstatten (durch die Operation Entnehmen) 
lassen oder den Gutschein bzw. die Quittung nur einfach vorweisen (durch Lesen). 
Durch das Aufbringen von VAS-Daten erfolgt somit ein implizites Laden von VAS- 
Applikationen der Implementierungsklasse EFJTRANSFER. Fur diese 
Applikationsklasse existiert die Implementierungsklasse EFJTRANSFER, die aus 
25 einzelnen Objekten der Art Record besteht. Ein Eintrag in EFJTRANSFER ist 
ausschliefilich durch das Kommando TRANSFER moglich. Das Handlerterminal 
muB dazu im Besitz eines gultigen Entwerter-Schliissels K DEC sein und uber eine 
PIX A der VAS-Applikation A verfllgen. 

30 Ablaut des Aufbringens von VAS-Daten : 

1 . Der Karteninhaber fuhrt eine VAS-Karte in ein Handlerterminal ein. 

2. Das Handlerterminal pruft, ob ein VAS-Container vorhanden ist: 



# 
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• SELECT FILE < AIDvas > (Fehlermeldung wenn VAS-Container nicht 
selektierbar) 

• READ RECORD < SFI von EFJD, 0 > (Auslesen der VAS-Container 



3. Das Handlerterminal liest die Sequenznummer, die zusatzlich in den MAC aus 
Schritt 4 eingeht: 

• READ RECORD < SFI von EF_SEQ, 0 > (Auslesen der Sequenznummer) 

10 4. Mit dem Kommando TRANSFER wird in EF_TRANSFER ein Record 
geschrieben: 

• TRANSFER <Transaktionsdatum, Verfallsdatum, Erzeugercode, Daten, 



5. Das H§ndlerterminal kann durch Priifung der Antwortnachricht des TRANSFER 
Kommandos priifen, ob der VAS-Container echt ist (d.h. in Besitz des 
gemeinsamen Geheimnisses Ko EC ist). Wir verweisen hierzu auch auf die vorher 
beschriebene Antwortnachricht des Kommandos TRANSFER. 

20 

Schlielilich das Erwerben von VAS-Daten durch Entwerten 

Ein VAS-Provider kann durch einen Entwertevorgang mit dem Kommando 
TRANSFER im Transferfeld EF_TRANSFER ein Anrecht (z.B. Gutschein oder 
25 Quittung) erzeugen, das von einem anderen VAS-Provider weiter verwertet werden 
kann. Entwertet werden Daten aus dem EF_VALUE bzw. EFJNFO der VAS- 
Applikation A des entwertenden VAS-Provider. Der Karteninhaber erwirbt in Form 
eines Objektes in EF_TRANSFER das Anrecht. 

30 Ablauf des Aufbringens von VAS-Daten: 



5 



Nummer) 



PIX A , MAC mit K 0EC > 



1. Der Karteninhaber fuhrt eine VAS-Karte in ein Handlerterminal ein. 



# 

WO 98/28718 



PCT/DE97/03012 



2. Das Handlerterminal prCft, ob ein VAS-Container vorhanden ist: 

• SELECT FILE < AIDvas > (Fehlermeldung wenn VAS-Container nicht 
5 selektierbar) 

• READ RECORD < SFI von EFJD, 0 > (Auslesen der VAS-Container ID) 

3. Das Hdndlerterminal liest die Sequenznummer, die zusatzlich in den MAC aus 
Schritt 4 eingeht: 

10 

• READ RECORD < SFI von EF_SEQ, 0 > (Auslesen der Sequenznummer) 

4. Das Handlerterminal selektiert die VAS-Applikation A: 

15 • SELECT FILE < PIX A > (Fehlermeldung, falls VAS-Applikation A nicht in 

den VAS-Container geladen ist) 

5. Das Handlerterminal nutzt das Kommando TRANSFER zum Entwerten der 
Daten aus dem EF_VALUE bzw. dem EFJNFO. 

20 

• TRANSFER < Daten, MAC mit Ko EC > 

Die Zusammensetzung der Kommandonachricht von TRANSFER wurde 
bereits beschrieben. Die Berechtigung zum Entwertevorgang erlangt das 
Terminal, wenn es eine korrekte Signatur Qber die Daten mit dem 
25 SchlQssel K DEC bilden kann. Diese wird durch den VAS-Container geprtift. 

Bei Erfolg wird vom VAS-Container ein Record in EF_TRANSFER angelegt 
sowie die Sequenznummer inkrementiert. 

6. Das Handlerterminal kann durch Prtifung der Antwortnachricht des TRANSFER 
30 Kommandos prufen, ob der VAS-Container echt ist (d.h. in Besitz des 

gemeinsamen Geheimnisses Kdh C ist). 
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Und nun noch das Verfahren zum Entwerten von VAS-Daten. Es gibt zwei Arten 
von Entwertungsvorgangen: 

Zum einen kSnnen VAS-Daten fQr VAS-Applikationen der Implementierungsklasse 
5 DF_PT oder DF_AD durch den zugehflrigen VAS-Provider entwertet werden durch 
die Operation Entwerten, d.h. Erwerben von VAS-Daten durch Entwerten. Dadurch 
wird ein Wert verbraucht, wobei ein potentielles Anrecht auf einen weiteren Wert 
entsteht. 

10 Zum anderen konnen VAS-Daten aus dem EF_TRANSFER einmalig entnommen 
werden mit dem Erganzungskommando TAKE. In diesem Fall wird das Anrecht 
aufgebraucht, die Daten bleiben fur etwaige weitere Verwendung (z.B. 
rfickerstattetes Ticket wird zur RQckfahrt noch benbtigt) im Transferfeld als 
entnommen gekennzeichnet stehen, bis sie bei Bedarf von anderen Objekten 

15 uberschrieben werden. 

Ablauf des Entwertens von VAS-Daten durch das Kommando TAKE: 

1. Der Karteninhaber fuhrt eine VAS-Karte in ein Handlerterminal ein. 

20 

2. Das Handlerterminal prtift, ob ein VAS-Container vorhanden ist: 

• SELECT FILE < AID VA s > (Fehlermeldung wenn VAS-Container nicht 
selektierbar) 

• READ RECORD < SFI von EFJD, 0 > (Auslesen der VAS-Container ID) 

25 

3. Zunachst liest das Handlerterminal die zur VerfOgung stehenden Objekte aus 
EF_TRANSFER aus mit dem Spezialfall der Operation Ansehen W\S- 
Applikationen, urn zu entscheiden, ob ein gesuchtes Objekt enthalten ist. 
Alternativ kann mit dem Kommando SEEK nach einem Muster gesucht werden. 

30 Das Terminal kennt im Erfolgsfall die Nummer i des gesuchten Records. 
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4. Das Terminal markiert den Record mit Recordnummer i als entfemt, indem es i, 
eine von ihm berechnete Zufallszahl, seine PIX und Terminal ID mit dem 
Kommando TAKE Qbermittelt: 

• TAKE < i, Zufallszahl, PIX, Terminal ID > 

Das Handlerterminal nutzt das Kommando TAKE zum Lesen der Daten aus dem 
EF_TRANSFER bei gleichzeitigem Kennzeichnen der Daten als entnommen. 
Die AusfQhrung des Kommandos bewirkt zusatzlich die Erzeugung von zwei 
verschiedenen Kryptogrammen und C 2 . 

Das Kryptogramm C, wird durch den VAS-Container mit dem Schlussel 
Ksig vasc berechnet. Damit kann der Einreicher des entnommenen, mit 
signierten Objektes sich beim System Operator die Einmaligkeit und Echtheit 
nachweisen lassen. Die Einmaligkeit und Echtheit der Transaktion ergibt sich 
aus dem Kryptogramm des VAS-Providers t von dem das Objekt ursprtinglich 
stammt (und die von der Karte geprQft wurde, siehe TRANSFER), und der 
FQhrung eines SequenzzShlers Qber die Transaktionen sowie dem Kryptogramm 
durch die Karte bei der Entnahme. 

Das Kryptogramm C 2 wird durch den VAS-Container mit dem Schlussel K DEC 
berechnet, der von dem VAS-Container aus KGK 0EC , PIX und Terminal ID 
abgeleitet wird. Durch Kenntnis des gemeinsamen Geheimnisses K DEC kann der 
VAS-Container dem Terminal gegenOber direkt die Echtheit des VAS-Containers 
beweisen. Da beim TRANSFER Kommando ebenfalls geprQft wird, dad nur 
echte Gutscheine bzw. Quittungen in einen echten VAS-Container gepeichert 
werden, kann daraus die Echtheit des entnommenen Objektes gefolgert werden. 
Da C 2 indirekt Qber die Sequenznummer, das Entnommen-Bit und die VAS- 
Container ID gebildet wird, kann der VAS-Container dem Terminal sogar die 
Einmaligkeit des entnommenen Objektes nachweisen. 

Die Berechtigung zum Entnehmen mit dem Kommando TAKE hat jeder. 
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Am Serviceterminal ist ferner die DeaktMerung bzw. Aktivierung eines PalJwort- 
Oder PIN-Schutzes fur das Lesen von VAS-Applikationen der Implementierungs- 
klassen DF_PT und DF_AD mdglich. AuBerdem kann die PIN des VAS-Containers 
5 vom Karteninhaber durch der Kenntnis der PIN geSndert werden und vom System 
Operator mittels extemer Authentifizierung durch K s0 zurilckgesetzt werden. Als 
PIN oder Paliwort sind auch nicht-numerische Zeichen oder Zeichenketten 
beiiebiger Ldnge verwendbar. 
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PatentansprOche 



1 . Chipkarte, die zur Durchftihrung von Transaktionen dient f bei denen 
geldwerte Einheiten oder andere nicht-monetare Anspriiche reprasentierende 
Wertdaten zwischen dem Karteninhaber und mindestens einem 
Transaktionspartner (Service-Provider) Qbertragen Oder dem Service-Provider zur 
Verifizierung der AnsprOche vorgewiesen werden, wobei die Chipkarte einen 
Speicher umfaftt, in dem zur Durchfuhrung der Transaktionen erfordertiche Daten 
abgespeichert werden, und die Chipkarte dadurch gekennzeichnet ist, daft sie 
folgendes aufweist: 

eine Einrichtung zum Laden von einer oder mehreren 
Kartenanwendungen (VAS-Applikationen) auf die Karte, die jeweils die 
DurchfQhrung von Transaktionen zwischen dem Karteninhaber und einem oder 
mehreren Service-Provider ermOglichen. 

2. Chipkarte nach Anspruch 1, bei der die Einrichtung zum Laden 
folgendes aufweist: 

eine darin abgespeicherte Datenstruktur (DF_VAS, VAS-Container), die 

aufweist: 

eine Teilstruktur (DF_PT, DF_AD, VAS-Applikation), in die zur 
Ermdgiichung der Durchfuhrung einer Transaktion zwischen dem Karteninhaber 
und einem Service-Provider erforderliche Daten (VAS-Daten) geladen werden 
konnen; 

einen Definitionsdatensatz, der Informatipnen uber die Art und/oder 
Struktur der in der Teilstruktur (VAS-Applikation) abgespeicherten Daten enthSIt; 
wobei der Definitionsdatensatz ferner aufweist: 

eine die Datenstruktur (VAS-Container) und/oder die Chipkarte 
identifizierende Kennung (Container-ID); und 

mindestens einen System-Schlussel (K so ), der die Integritat des 
Definitionsdatensatzes und/oder der Datenstruktur (VAS-Container) gegen 
Modifikationen absichert. 
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3. Chipkarte nach Anspaich 1 oder 2, dadurch gekennzeichnet, dali sie 
ferner aufweist: 

einen Transfer-Speicherbereich (EF_TRANSFER) zur Aufnahme von bei 
5 der Durchfiihrung der Transaktion auszutauschenden oder vorzuweisenden die 
geldwerte Einheiten oder nicht monetaren Ansprilche reprSsentierenden Daten; 
und 

eine Einrichtung zum Schreiben von Daten in den Transferspeicher in 
Reaktion auf ein Schreibkommando (Transfer). 

10 

4. Chipkarte nach einem der AnsprOche 1 bis 3, dadurch 
gekennzeichnet, daft sie weiterhin mindestens eines der folgenden Merkmale 
aufweist: 

eine Einrichtung zum Laden von fur die DurchfDhrung von Transaktionen 
15 erforderlichen Daten in die Teilstruktur unter Verwendung des mindestens einen 
Systemschlussels; 

eine Einrichtung zum Schreiben von Daten in den Definitionsdatensatz 
zum Anpassen der Daten des Definitionsdatensatzes an die in die Teilstruktur 
geladenen Daten; 

20 eine Einrichtung zum Generieren einer weiteren Teilstruktur, in die zur 

DurchfOhrung einer Transaktion erforderliche Daten geladen werden kdnnen, in 
dem Speicher der Karte; und/oder 

eine Einrichtung zur dynamischen Speicherverwaltung auf der Karte. 

25 5. Chipkarte nach einem der vorhergehenden AnsprOche, dadurch ge- 

kennzeichnet, dafi 

es sich bei den Teilstrukturen (VAS-Applikationen) urn voneinander 
unabhangige Teilstrukturen handelt, die jeweils einem bestimmten Service-Provider 
zugeordnet sind, 

30 der Definitionsdatensatz mittels des mindestens einen Systemschlussels 

(Kso) gegen Modifikationen geschutzt ist und nur mittels dieses SchlQssels 
modifiziert werden kann, und dafi 
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das Laden der Teilstrukturen (VAS-Applikationen) nur unter Verwendung 
des im Definitionsdatensatz enthaltenen Systemschliissels erfolgen kann. 

6. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch ge- 
5 kennzeichnet, daft der Definitionsdatensatz ferner mindestens eines der folgenden 
Merkmale aufweist: 

mindestens einen Authentifizierungsschlussel (K AUT ) zur 
Authentifizierung der Berechtigung der Chipkarte gegenOber einem Terminal 
und/oder zur Authentifizierung der Berechtigung eines Terminals gegenOber der 
10 Chipkarte; 

mindestens einen SignierschlQssel (K S | GV asc) zum Signieren von aus 
dem Transferspeicher entnommenen Daten; 

einen SchlOsselerzeugungs-SchlOssel (KGK DEC ) zur Erzeugung von 
terminal- und applikationsspezifischen SchlOsseln zur Oberpriifung der 
15 Berechtigung eines Schreibvorgangs in den Transferspeicher und/oder einer 
Entwertung von Wertdaten; 

eine PIN zur Verifikation der Berechtigung eines Transaktionsvorgangs 
durch den Karteninhaber, 

dafi der SystemschlOssel (K so ), der AuthentizifierungsschlQssel (K AUT ), 
20 der SignierschlQssel (K S , G _ VASC ) und der SchlOsselerzeugungs-SchlOssel (KGKqec) 
kartenindividuelle oder datenstruktur-(DF_VAS)-spezifische Schlussel sind, 

und daB die Teilstruktur (VAS-Applikation) mindestens eines der 
folgenden Merkmale aufweist: 

mindestens einen Wertspeicher (EF_VALUE) zur Aufnahme von 
25 Wertdaten; 

mindestens einen Intem-Speicher (EFJNTERNAL) zur Aufnahme von 
intemen die Teilstruktur betreffenden Daten; 

mindestens einen Infospeicher (EFJNFO) zur Aufnahme von nicht 
intemen die Teilstruktur betreffenden Daten; 
30 einen SchlOsselspeicher (EF_KEY) zur Aufnahme mindestens eines 

SchlOssels (Klvasp. K RVA sp). die Schreib- und/oder Lesevorgange in den oder aus 
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dem Wertspeicher, und/oder dem Intem-Speicher und/oder dem Info-Speicher 
absichem, und dali die Chipkarte femer umfalit: 

eine Einrichtung zum Schreiben und/oder Lesen von Daten in den oder 
aus dem Wertspeicher, dem Intern-Speicher und dem Infospeicher, und daft die 
5 Einrichtung zum Laden umfalit: 

eine Einrichtung zum Schreiben der SchlQssel in den Schlusselspeicher 
unter Absicherung durch den mindestens einen Systemschlussel. 

7. Chipkarte nach einem der vorhergehenden AnsprQche, dadurch ge- 
10 kennzeichnet, dafi die Teilstruktur mindestens eines der foigenden Merkmale 

aufweist: 

einen Schlussel (K LVASP ) zum Oberpriifen der Schreibberechtigung von 
Daten in die Teilstruktur; 

einen Schlussel (K RVA sp) zum Oberpriifen der Leseberechtigung von 
15 Daten aus der Teilstruktur. 

8. Chipkarte nach einem der vorhergehenden AnsprQche, dadurch ge- 
kennzeichnet, dad die im Schlusselspeicher abgespeicherten Schlussel fur die 
jeweilige Teilstruktur spezifisch sind und dali 

20 die mindestens eine Teilstruktur (VAS-Applikation) das DurchfOhren von 

Transaktionen mittels mindestens eines der spezifischen Schlussel (K LVASPl K RVASP ) 
absichert, der fur die jeweilige Teilstruktur (VAS-Applikation) spezifisch und von 
den SchlQsseln anderer Teilstrukturen (VAS-Applikationen) unabhangig ist. 

25 9. Chipkarte nach einem der vorhergehenden AnsprQche, dadurch ge- 

kennzeichnet, dafi 

die Karte mehrere der Teilstrukturen (VAS-Applikationen) aufweist, die 
jeweils zur Durchfuhrung von Transaktionen zwischen einem bestimmten Service- 
Provider und dem Karteninhaber dienen, und daB 

30 das DurchfOhren von Transaktionen das Schreiben und/oder Lesen von 

Daten in das bzw. aus dem Transferfeld und/oder das Schreiben und/oder Lesen 
von Daten in den bzw. aus dem Wertspeicher umfalit. 
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10. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch ge- 
kennzeichnet, dad sie ferner umfalit: 

eine Einrichtung zum DurchfQhren von Transaktionen sowohl zwischen 
5 einzelnen Teilstrukturen (VAS-Applikationen) als auch zwischen einer Teilstruktur 
und einem Service-Provider. 

11. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch ge- 
kennzeichnet, dad 

10 der System-SchlQssel (K so ) nur dem Systembetreiber (System Operator 

SO) bekannt ist und ein kartenindividueller und/oder Datenstruktur-(VAS- 
Container)-spezifischer SchlQssel ist, und daft 

die weiteren im Definitionsdatensatz enthaltenen SchlQssel 
kartenindividuelle und/oder Datenstmktur-(VAS-Container)-spezifische SchlQssel 

15 sind. 

12. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch ge- 
kennzeichnet, daB der Definitionsdatensatz eines oder mehrere der folgenden 
Merkmale aufweist: 

20 eine die Datenstruktur spezifizierende Identifikationsnummer (EFJD) 

ein Verzeichnis der in der Datenstruktur enthaltenen Teilstrukturen 
(EF_DIR), wobei das Verzeichnis teilstrukturspezifische Identifikationsnummern 
von in der Datenstruktur (VAS-Container) geladenen Teilstrukturen (VAS- 
Applikationen) enthait, sowie Informationen Qber den Teil der Datenstruktur (VAS- 

25 Container), in dem die Teilstrukturen (VAS-Applikationen) physikalisch gespeichert 
sind; 

eine Versionsnummer der Datenstruktur (EF_VERSION). 

13. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch ge- 
30 kennzeichnet, daft sie mindestens eines der folgenden Merkmale umfaBt: 
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eine Einrichtung zur Durchfuhrung eines Entnahmevorgangs (Take), 
mittels dessen Daten aus dem Transferspeicher entnommen und/oder entwertet 
werden; 

eine Einrichtung zur Erzeugung eines Oder mehrerer Echtheitsmerkmale 
der Daten bei Entnahme bzw. der Entwertung von Daten aus dem 
Transferspeicher. 

14. Chipkarte nach einem der vorhergehenden AnsprOche, dadurch 
gekennzeichnet, daft die Chipkarte zur Generierung der Echtheitsmerkmale 
folgendes aufweist: 

einen Signierschliissel K SIG _ VASC zum Erzeugen einer digitalen Signatur 
Qber den entnommenen Daten; 

eine Einrichtung zur Erzeugung einer die Transaktion kennzeichnenden 
Transaktionsnummer, die zur Erzeugung der digitalen Signatur mitverwendet wird. 

15. Chipkarte nach einem der vorhergehenden AnsprOche, dadurch 
gekennzeichnet, daft 

der SignierschlQssel K SIGVASC ein aus einem privaten Key-Generating- 
Key abgeleiteter privater Schlussel ist und zur Oberpriifung der Signatur durch die 
Serviceprovider Sffentliche SchlOssel herangezogen werden. 

16. Chipkarte nach einem der vorhergehenden AnsprOche, dadurch ge- 
kennzeichnet, daft sie mindestens eines der folgenden Merkmale umfaftt: 

eine Einrichtung zur Erzeugung von terminal- und 
teilstrukturspezifischen Schlusseln (K DEC ) mittels des Schlusselerzeugungs- 
Schlussels (KGKdec); 

eine Einrichtung zur Verifizierung der RechtmSftigkeit und/oder der 
Absicherung einer Transaktion unter Verwendung mindestens eines der folgenden 
Merkmale: 

des terminal- und teilstrukturspezifischen SchlQssels (K DEC ), 
des mindestens einen AuthentifizierungsschlOssels (K AUT ), 
des mindestens einen SystemschlOssels (Kso), 
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des mindestens einen teilstrukturspezifischen SchlOssels (K LVASP , 

Krvasp)» 

des Signierschlussels (K SIG V asc). 
der PIN, 

der Kennung einer Teilstruktur, 
der Kennung eines Terminals. 

17. Chipkarte nach einem der vorhergehenden Ansprtiche, dadurch 
gekennzeichnet, daft die Chipkarte ferner mindestens eines der folgenden 
Merkmale umfaftt: 

eine Einrichtung zum Authentifizieren der Berechtigung und/oder des 
Terminals mittels des AuthentifizierungsschlQssels bevor ein Lese- oder 
Schreibvorgang gestartet wird, 

eine Einrichtung zur DurchfQhrung von Lese- Oder Schreibvorgangen, 
die mit einer digitalen Unterschrrft und/oder VerschlQsselung gesichert sind. 

18. Chipkarte nach einem der vorhergehenden Ansprtiche, dadurch 
gekennzeichnet, daft die Chipkarte femer mindestens eines der folgenden 
Merkmale umfaftt: 

eine Einrichtung zum Aktivieren und Deaktivieren des PIN-Schutzes, 
eine Einrichtung zum Abandern der PIN. 

19. Chipkarte nach einem der vorhergehenden Ansprtiche, dadurch 
gekennzeichnet, daft 

die Datenstruktur gemaft einem der vorhergehenden Ansprtiche von der 
Kartenplattform unabhangig ist und die Chipkarte femer umfaftt: 

eine Einrichtung zum Obertragen der Datenstruktur Oder von Teilen der 
Datenstruktur auf eine andere Karte. 

20. Chipkarte, dadurch gekennzeichnet, daft sie folgendes aufweist: 
einen Speicherbereich zum Schreiben oder Lesen von Daten in den 

oder aus dem Speicherbereich zum Transfer von geldwerten Einheiten und/oder 
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von anderen nicht-monetaren AnsprQche reprasentierenden Wertdaten zwischen 
identischen Oder unterschiedlichen Service-Providern. 

21. Terminal zur Verwendung mit einer Chipkarte gemaii einem der 
AnsprQche 1 bis 20, dadurch gekennzeichnet, dali das Terminal umfalit: 

eine Einrichtung zum Identifizieren der Datenstruktur (VAS-Container) 
der Chipkarte sowie zur Identifikation der die Datenstruktur identifizierenden 
Kennung (Container-ID); 

und dali es ferner mindestens eines der folgenden Merkmale umfalit: 

eine Einrichtung zum Lesen von Daten aus mindestens einer der 
Teilstrukturen und/oder dem Definitionsdatensatz und/oder dem Transferspeicher 
der Karte; 

eine Einrichtung zum Schreiben von Daten in den Transferspeicher der 

Karte; 

eine Einrichtung zum Laden der zur Durchfuhrung von Transaktionen 
erforderlichen Daten in mindestens eine der Teilstrukturen (VAS-Applikationen) der 
Karte. 

22. Terminal nach Anspruch 21, dadurch gekennzeichnet, daft es ferner 
mindestens eines der folgenden Merkmale aufweist: 

eine Einrichtung zur DurchfQhrung von Transaktionen zwischen einem 
Service-Provider und dem Karteninhaber, wobei das DurchfOhren einer Transaktion 
mindestens einen der folgenden Schritte umfalit: 

das Schreiben von Daten in den Wertspeicher, 

das Schreiben von Daten in den Transferspeicher, 

das Entnehmen und/oder Entwerten von Daten aus dem 
Transferspeicher, 

das Lesen von Daten aus der Teilstruktur, 

das Lesen von Daten aus dem Transferspeicher. 

23. Terminal nach einem der AnsprQche 21 oder 22, dadurch 
gekennzeichnet, daft es ferner umfalit: 
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eine Einrichtung zur Verifizieaing der Rechtmaftigkeit und/oder der 
Absicherung einer Transaktion unter Verwendung mindestens eines der folgenden 
Merkmale: 

eines terminal- und teilstrukturspezifischen SchlQssels (K DEC ) t 
5 des mindestens einen kartenindividuellen oder datenstruktur-(DF_VAS)- 

spezifischen AuthentifizierungsschlQssels (K AUT ), 

des mindestens einen kartenindividuellen oder datenstruktur-(DF_VAS)- 
spezifischen SystemschlOssels (K so ), 

des mindestens einen teilstrukturspezifischen SchlQssels (K LV asp> 

10 K RV asp)i 

des kartenindividuellen oder datenstruktur-(DF_VAS)-spezifischen 
Signierschlussels (K SIG V asc)» 

der kartenindividuellen oder datenstruktur-(DF_VAS)-spezifischen PIN, 
der applikationsspezifischen Kennung einer Teilstruktur, 
15 der terminalspezifischen Kennung eines Terminals. 

24. Terminal nach einem der Anspruche 219 bis 23, dadurch 
gekennzeichnet, dall die Einrichtung zum Schreiben von Daten in den 
Transferspeicher aufweist: 

20 eine Einrichtung zum Verschlusseln von Daten unter Verwendung eines 

terminal- und teilstrukturspezifischen SchlQssels (K DEC ) zum Nachweis der 
Schreibberechtigung. 

25. Terminal nach einem der AnsprQche 21 bis 24, dadurch 
25 gekennzeichnet, daft es ferner aufweist: 

eine Einrichtung zum DurchfQhren eines Entnahmevorgangs von Daten 
aus dem Transferspeicher, mittels dessen Daten aus dem Transferspeicher 
entnommen und/oder entwertet werden. 



30 26. Terminal nach einem der Anspruche 21 bis 25, dadurch 

gekennzeichnet, dali es ferner mindestens eines der folgenden Merkmale aufweist: 
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eine Einrichtung zum Kennzeichnen von Daten des Transferspeichers 
als entnommen, 

eine Einrichtung zum Kennzeichnen von Daten des Transferspeichers 
als verfallen. 

5 

27. Terminal nach einem der AnsprQche 21 bis 26, dadurch 
gekennzeichnet, daft die Einrichtung zum DurchfOhren von Transaktionen 
mindestens eines der folgenden Merkmale aufweist: 

eine Einrichtung zum Andern von Wertdaten in der Teilstruktur; 
10 eine Einrichtung zum DurchfOhren von Transaktionen zwischen 

verschiedenen Service-Providern (Interservices) auf Kosten bzw. zum Nutzen des 
Karteninhabers. 



28. Terminal nach einem der Anspruche 21 bis 27, dadurch 
15 gekennzeichnet, daft es ferner aufweist: 

eine Einrichtung zum Authentifizieren der Berechtigung des Terminals 
gegenuber der Karte und/oder der Karte gegenuber dem Terminal unter 
Verwendung mindestens eines Authentifizierungsschlussels; 

eine Einrichtung zum Absichem einer Transaktion durch den 
20 Karteninhaber mittels einer PIN; 

eine Einrichtung zum Aktivieren und Deaktivieren des PIN-Schutzes. 

29. Terminal nach einem der Anspruche 21 bis 28, dadurch 
gekennzeichnet, daft es ferner mindestens eines der folgenden Merkmale aufweist: 

25 eine Einrichtung zum Obertragen einer terminalspezifischen Kennung an 

die Karte; 

eine Einrichtung zum Obertragen einer die Teilstruktur spezifizierenden 
Kennnung an die Karte; 

eine Einrichtung zum Authentifizieren der Berechtigung unter 
30 Verwendung eines terminal- und teilstrukturspezifischen SchlQssels sowie der 
terminal- und teilstrukturspezifischen Kennung, 
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eine Einrichtung zur Durchfiihrung von Lese- Oder Schreibvorgangen, 
die mit einer digitalen Unterschrift und/oder VerschlQsselung gesichert sind. 

30. Terminal nach einem der AnsprQche 21 bis 29, dadurch 
5 gekennzeichnet, da(J es ferner mindestens eines der folgenden Merkmale aufweist: 

eine Einrichtung zum Selektieren einer Teilstmktur (VAS-Applikation); 
eine Einrichtung zum Ansehen einer Teilstruktur auf dem Terminal; 
eine Einrichtung zum Ansehen der Daten einer Teilstruktur auf dem 

Terminal; 

10 eine Einrichtung zum Laden einer Teilstruktur (VAS-Applikation) auf die 

Karte; 

eine Einrichtung zum Laden einer Kennung einer geladenen Teilstruktur 
(VAS-Applikation) auf die Karte, 

eine Einrichtung zum Loschen einer Teilstruktur von der Karte; 
15 eine Einrichtung zum Substituieren einer Teilstruktur durch eine andere 

Teilstruktur, 

eine Einrichtung zum Obertragen einer Teilstruktur auf eine andere 

Karte; 

eine Einrichtung zum Interpretieren einer Teilstruktur bezQglich ihrer 
20 Funktion und ihres zugeordneten Service-Providers sowie zum Lesen und 
Ansehen von in ihr gespeicherten Informationen. 

31. Verfahren zum Durchfuhren von Transaktionen zwischen einem 
Karteninhaber und mindestens einem Service-Provider unter Verwendung einer 

25 Chipkarte sowie eines Terminals, wobei das Verfahren einen der folgenden 
Schritte umfaRt: 

Vorsehen einer auf der Chipkarte abgespeicherten Datenstruktur, in die 
zur Ermdglichung der Durchfiihrung der Transaktion zwischen dem Karteninhaber 
und einem Service-Provider erforderliche Daten (VAS-Daten) geladen werden 
30 k6nnen, sowie Schreiben oder Lesen von Daten in die/aus der Datenstruktur (VAS- 
Applikation); 
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Vorsehen eines Transfer-Speicherbereichs (EF_TRANSFER) zur 
Aufnahme von bei der Durchfuhrung der Transaktion auszutauschenden Oder 
vorzuweisenden die Geldwerteeinheiten Oder nicht-monetaren AnsprQche 
reprasentierenden Daten, sowie Schreiben von Daten in den Transferspeicher Oder 
Lesen von Daten aus dem Transferspeicher. 

32. Verfahren nach Anspruch 31, dadurch gekennzeichnet, da(i das 
Verfahren mindestens einen der folgenden Schritte umfaftt: 

Verwendung einer Chipkarte gemaii einem der AnsprQche 1 bis 20; 

Verwendung eines Terminals gemSR einem der AnsprQche 21 bis 30; 

Schreiben oder Lesen von Daten in den/aus dem Wertspeicher oder 
Intern-Speicher oder Info-Speicher von mindestens einer der Teilstrukturen (VAS- 
Applikationen). 

33. Verfahren nach Anspruch 31 oder 32, dadurch gekennzeichnet, da& 
es femer mindestens einen der folgenden Schritte umfaftt: 

Authentifizieren der Berechtigung des Terminals und/oder der Chipkarte 
unter Verwendung mindestens eines SchlQssels; 

Absichern der Transaktion durch Verwendung einer digitalen Unterschrift 
und/oder VerschlQsselung durch Verwendung mindestens eines SchlQssels. 

34. Verfahren zum Laden von Daten auf eine Chipkarte unter 
Verwendung eines Terminals, dadurch gekennzeichnet, dafl das Verfahren 
mindestens einen der folgenden Schritte umfallt: 

Laden von Daten in eine Teilstruktur (VAS-Applikation) der Karte; 
Schreiben von Daten in den Definitionsdatensatz der Karte. 

35. Verfahren zum Laden von Daten nach Anspruch 34, welches 
mindestens einen der folgenden Schritte umfaBt: 

Verwendung einer Chipkarte gemaii einem der AnsprQche 1 bis 20; 
Verwendung eines Terminals gemail einem der AnsprQche 21 bis 30. 
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36. System zur DurchfOhrung von Transaktionen, gekennzeichnet durch: 
eine Chipkarte gemaft einem der AnsprOche 1 bis 20 und 
ein Terminal gemaB einem der AnsprOche 21 bis 30. 
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